Fix inconsistent $this behavior

[dstogov]

No description provided.

[laruence]

it's better to use zend_string_equals(Z_STR(final_name), CG(known_string)[THIS_STR[)

[nikic]

From a quick scan, it looks like handling for by-reference fetches of $this is missing. A by-ref fetch should not throw the undefined variable notice if $this does not exist. (And for function arguments by-ref may be dynamic, so do we also need a FUNC_ARG variant of this?)

[dstogov]

@nikic it's possible to pass or assign $this by reference, but this assignment is actually done by value and changes to reference won't affect value of $this.

[nikic]

@dstogov Yeah, I did understand that. What I'm referring to is that reference assignment usually suppresses the "undefined variable" notice, but in this case it would still be there, right? Though probably this doesn't matter anyway.

[dstogov]

ah, right. I'll think about this.

---

From: Nikita Popov notifications@github.com
Sent: Thursday, May 26, 2016 2:01:01 AM
To: php/php-src
Cc: Dmitry Stogov; Mention
Subject: Re: [php/php-src] Fix inconsistent $this behavior (#1918)

@dstogovhttps://github.com/dstogov Yeah, I did understand that. What I'm referring to is that reference assignment usually suppresses the "undefined variable" notice, but in this case it would still be there, right? Though probably this doesn't matter anyway.

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHubhttps://github.com//pull/1918#issuecomment-221732782

[nikic]

@dstogov Tangentially related, as it would solve the issue with references as well: Shouldn't any access to $this, apart from isset($this), throw the same error exception you get on $this->foo and similar? It seems inconsistent that $this->foo; and $that = $this; $that->foo; behave very differently if $this is not defined. In one case you get an error exception, in the other you get a notice and warning. As long as isset($this) does not throw, this still keeps BC with the "can use method statically and non-statically" pattern.

[dstogov]

@nikic, good point. I followed your suggestion and changed RFC and implementation accordingly. Now we will get "Using $this when not in object context" exception everywhere.

[ml-]

<?phperror_reporting(E_ALL);
class Foo {
function__construct() {
$this->bar($this);
var_dump($this);
}
publicfunctionbar(&$that) {
$that = "Bar";
}
}
$q = newFoo();

master

string(3) "Bar"

dstogov/this_var

object(Foo)#1 (0) {
}

Works.
However, no Warning emitted or Exception thrown in this case.

[dstogov]

Right. This case is covered by corresponding RFC section https://wiki.php.net/rfc/this_var#disable_ability_to_re-assign_this_indirectly_through_reference

---

From: Matthias Lisin notifications@github.com
Sent: Tuesday, May 31, 2016 6:55:52 PM
To: php/php-src
Cc: Dmitry Stogov; Mention
Subject: Re: [php/php-src] Fix inconsistent $this behavior (#1918)

bar($this); var_dump($this); } ``` public function bar(&$that) { $that = "Bar"; } ``` } $q = new Foo(); master string(3) "Bar" dstogov/this_var object(Foo)#1 (0) { } Works. However, no Warning emitted or Exception thrown in this case. ## You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com//pull/1918#issuecomment-222733471, or mute the threadhttps://github.com/notifications/unsubscribe/ACZM0hZB4bDoLS4OP4oL9SYc24pT2budks5qHFoIgaJpZM4Iky76.

[staabm]

Should it also emit a warning/notice in this case?

[nikic]

This should add inference for the new FETCH_THIS opcodes.

[dstogov]

done

[Majkl578]

This RFC targets 7.1 although introduces mutliple BC breaks. It seems like a violation of PHP's own release process:

x.y.z to x.y+1.z

• Backward compatibility must be kept

[nikic]

This should probably use result (or the result variable can be dropped instead).