[RFC] Fix inconsistent behavior of $this variable

7 years ago by Dmitry Stogov — view source

unread

Hi internals,

Please review the RFC.

It proposes to fix all known inconsistencies related to handling of special $this variable.

https://wiki.php.net/rfc/this_var

Thanks. Dmitry.

7 years ago by Nikita Popov — view source

unread

Hi internals,

Please review the RFC.

It proposes to fix all known inconsistencies related to handling of
special $this variable.

https://wiki.php.net/rfc/this_var

Thanks. Dmitry.

How does this interact with things like extract() or get_defined_vars()?

The"static function __call()" case looks like a bug... Shouldn't this just
be a compiler error in the first place?

Nikita

7 years ago by Xinchen Hui — view source

unread

Hey:

Hi internals,

Please review the RFC.

It proposes to fix all known inconsistencies related to handling of
special $this variable.

in section static this, actually, the codes doesn't work in 7.0 neither.

it will result in fatal error: PHP Fatal error: Cannot re-assign $this

thanks

https://wiki.php.net/rfc/this_var

Thanks. Dmitry.

--
Xinchen Hui
@Laruence
http://www.laruence.com/

7 years ago by Dmitry Stogov — view source

unread

Hey:

On Tue, May 24, 2016 at 4:24 AM, Dmitry Stogov <dmitry@zend.com
mailto:dmitry@zend.com> wrote:
Hi internals,


Please review the RFC.

It proposes to fix all known inconsistencies related to handling
of special $this variable.
in section static this, actually, the codes doesn't work in 7.0 neither.

it will result in fatal error: PHP Fatal error: Cannot re-assign $this

Right. Thanks. Fixed.

Dmitry.

thanks
https://wiki.php.net/rfc/this_var


Thanks. Dmitry.
--
Xinchen Hui
@Laruence
http://www.laruence.com/

7 years ago by Jesse Schalken — view source

unread

I'm curious, what is it about $this that makes it special in the first
place? Can't it be a normal local variable that happens to already be
assigned at the start of a method?

Hi internals,

Please review the RFC.

It proposes to fix all known inconsistencies related to handling of
special $this variable.

https://wiki.php.net/rfc/this_var

Thanks. Dmitry.

7 years ago by Dmitry Stogov — view source

unread

I'm curious, what is it about $this that makes it special in the first
place? Can't it be a normal local variable that happens to already be
assigned at the start of a method?

In fact $this is not a regular local variable and it must not be
re-assigned.

Thank. Dmitry.

On Tue, May 24, 2016 at 6:24 AM, Dmitry Stogov <dmitry@zend.com
mailto:dmitry@zend.com> wrote:
Hi internals,


Please review the RFC.

It proposes to fix all known inconsistencies related to handling
of special $this variable.


https://wiki.php.net/rfc/this_var


Thanks. Dmitry.

7 years ago by Jesse Schalken — view source

unread

In fact $this is not a regular local variable and it must not be
re-assigned.

You're just restating the premise for my question. Why is it not a regular
local variable? Why must it not be reassigned?

7 years ago by Yasuo Ohgaki — view source

unread

Jesse,

In fact $this is not a regular local variable and it must not be
re-assigned.

You're just restating the premise for my question. Why is it not a regular
local variable? Why must it not be reassigned?

$this must be a object you're accessing.
If you can change $this, you'll suddenly loose object.

PHP 4 treated $this as regular variable and caused lots of problems.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

7 years ago by Jesse Schalken — view source

unread

Jesse,

$this must be a object you're accessing.

Why? I consider it a kind of implied parameter. You can reassign self in
Python for example.

class MyClass:
def foo(self, p1, p2):
self = 7
print(self, p1, p2)

c = MyClass()
c.foo(8, 3); # 7 8 3

I can't think of anything else that allows it, though.

If you can change $this, you'll suddenly loose object.

That's what tends to happen when you assign a variable.

PHP 4 treated $this as regular variable and caused lots of problems.

I'll have to take your word for it. I just thought the language would be
simpler with fewer "special" things that don't need to be special.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

7 years ago by Zeev Suraski — view source

unread

-----Original Message-----
From: jesseschalken@gmail.com [mailto:jesseschalken@gmail.com] On
Behalf Of Jesse Schalken
Sent: Tuesday, May 24, 2016 11:42 AM
To: Yasuo Ohgaki yohgaki@ohgaki.net
Cc: Dmitry Stogov dmitry@zend.com; internals internals@lists.php.net;
Nikita Popov nikic@php.net; Bob Weinand bwoebi@php.net; Xinchen Hui
laruence@php.net
Subject: Re: [PHP-DEV] [RFC] Fix inconsistent behavior of $this variable

On Tue, May 24, 2016 at 5:54 PM, Yasuo Ohgaki yohgaki@ohgaki.net
wrote:

Jesse,

$this must be a object you're accessing.

Why? I consider it a kind of implied parameter. You can reassign self in Python
for example.

Jesse,

You consider it an implied parameter, we considered it to be a representation of the currently scoped object at the language level.
Your way is not inherently wrong - but you know that already, as you've demonstrated other languages that allow this.
And while it's not wrong, it's also not the semantics we agreed upon for $this in PHP.

I'll have to take your word for it. I just thought the language would be simpler
with fewer "special" things that don't need to be special.

While we could debate whether it’s more or less special, an implied parameter is also special. So we wouldn't have fewer special things, just different ones.

Zeev

7 years ago by Rowan Collins — view source

unread

I'm curious, what is it about $this that makes it special in the first
place? Can't it be a normal local variable that happens to already be
assigned at the start of a method?

There are a few things that take advantage of its specialness, e.g.

binding a closure to an object changes the meaning of $this in a way
very different from assigning it into scope with "use($this)"
a method declared static can detect and throw errors on anything
referencing $this
when calling parent::foo() from an instance method, the value of $this
needs to be set appropriately on the new method; being able to reassign
$this could lead to some odd behaviour there

Python's approach is certainly valid, and leads to some different useful
properties, I'm sure, but it's a very different design, not just a more
relaxed attitude to assignment.

Regadrds,

Rowan Collins
[IMSoP]

7 years ago by Marc Bennewitz — view source

unread

I'm curious, what is it about $this that makes it special in the first
place? Can't it be a normal local variable that happens to already be
assigned at the start of a method?

There are a few things that take advantage of its specialness, e.g.

binding a closure to an object changes the meaning of $this in a way
very different from assigning it into scope with "use($this)"

a method declared static can detect and throw errors on anything
referencing $this

when calling parent::foo() from an instance method, the value of
$this needs to be set appropriately on the new method; being able to
reassign $this could lead to some odd behaviour there

Python's approach is certainly valid, and leads to some different
useful properties, I'm sure, but it's a very different design, not
just a more relaxed attitude to assignment.

As of $this is a very special variable where only the engine is (or
should) be allowed to change.
I would like to ask you if it wouldn't be better to NOT define $this as
a special variable
including a lot of code to make sure this variable doesn't get re-assigned
but instead define this as a keyword like self where the syntax makes
sure it can't be re-assigned
and it's less special and simpler to learn for beginners.

I know it would be a huge BC break but for me it sounds more "right" and
could also be introduced
in parallel to $this for a long long time but without a lot of
overplayed code for $this.

Thanks,
Marc

Regadrds,

7 years ago by Rowan Collins — view source

unread

As of $this is a very special variable where only the engine is (or
should) be allowed to change.
I would like to ask you if it wouldn't be better to NOT define $this
as a special variable
including a lot of code to make sure this variable doesn't get
re-assigned
but instead define this as a keyword like self where the syntax makes
sure it can't be re-assigned
and it's less special and simpler to learn for beginners.

It's an interesting concept, but most of the time $this does behave
like a variable - it's not just a way of accessing scope like "self".
You can write "foo($this)", "$bar = $this", even "echo $this" (if
__toString is defined). So any syntax that made it look unlike a
variable would have the opposite learning problem - how come I can use
it like a variable, but it looks like something else?

There's also rather a shortage of syntax that doesn't already mean
something...

Regards,

--
Rowan Collins
[IMSoP]

7 years ago by Stanislav Malyshev — view source

unread

Hi!

Please review the RFC.

It proposes to fix all known inconsistencies related to handling of special $this variable.

https://wiki.php.net/rfc/this_var

What is the reason behind all these changes? Does it serve some bigger
purpose? I'm not sure I currently see a reason to go to all these
lengths. Sure, you can re-assign $this and make things weird. But I
don't see why it's important to prevent it. It seems to add a lot of
code, including checks in various places that would slow down things
(and since these checks need to be done in each and every place we deal
with local variables, it is also a very brittle design - each time we
change or add anything there we'd need to remember forever to include
special case for "this").

Also notes:

How static __call is a thing? That looks like something that makes no
sense at all.
Why get_defined_vars() shouldn't show $this?

--
Stas Malyshev
smalyshev@gmail.com

7 years ago by Dmitry Stogov — view source

unread

Hi!

Please review the RFC.

It proposes to fix all known inconsistencies related to handling of special $this variable.

https://wiki.php.net/rfc/this_var
What is the reason behind all these changes? Does it serve some bigger
purpose?
I started from attempt to eliminate second internal way to access $this
variable.
This disclosed all these inconsistencies.

I'm not sure I currently see a reason to go to all these
lengths. Sure, you can re-assign $this and make things weird. But I
don't see why it's important to prevent it.
Keeping inconsistent behavior isn't good as well.

It seems to add a lot of
code, including checks in various places that would slow down things
(and since these checks need to be done in each and every place we deal
with local variables, it is also a very brittle design - each time we
change or add anything there we'd need to remember forever to include
special case for "this").
Actually, $this may be assigned to local variable in run-time only in 3
places: through $$, extract() and parse_str()/1.
If we remove this checks, we go back to 7.0 behavior - we create a local
variable $this, that has nothing in common with real internal $this
stored in EX(This).

Also notes:

How static __call is a thing? That looks like something that makes no
sense at all.

The same for me.
I got to know about static __call() and its special behavior from test
suite. :)
See tests/classes/__call_007.phpt

Why get_defined_vars() shouldn't show $this?

In most cases it doesn't show $this in 7.0.

Thanks. Dmitry.

7 years ago by Stanislav Malyshev — view source

unread

Hi!

Keeping inconsistent behavior isn't good as well.

It's not good, but it's not also very bad. Nobody really does that, so
whatever happens in these cases is mostly irrelevant.

Did you test performance impact of those changes?

Actually, $this may be assigned to local variable in run-time only in 3
places: through $$, extract() and parse_str()/1.

For now, maybe. But every time we do something with local symbol table,
we'd have to do special case for this. E.g., throretically, what if we
wanted to add function to Closure that allows to access to captured
scope - we'd need to special-case $this there. Etc...

If we remove this checks, we go back to 7.0 behavior - we create a local
variable $this, that has nothing in common with real internal $this
stored in EX(This).

That's not good, but maybe we could make them agree in some way?

In most cases it doesn't show $this in 7.0.

Right. But you're changing 7.0 behavior anyway?

--
Stas Malyshev
smalyshev@gmail.com

7 years ago by Dmitry Stogov — view source

unread

Hi!

Keeping inconsistent behavior isn't good as well.
It's not good, but it's not also very bad. Nobody really does that, so
whatever happens in these cases is mostly irrelevant.

For me it's easier to check and fix all inconsistencies at once.
I may set an additional voting question about performing these run-time
checks and throwing corresponding exception...

Did you test performance impact of those changes?
Of course. It's invisible on real-life apps even in terms of instruction
retired.

Actually, $this may be assigned to local variable in run-time only in 3
places: through $$, extract() and parse_str()/1.
For now, maybe. But every time we do something with local symbol table,
we'd have to do special case for this. E.g., throretically, what if we
wanted to add function to Closure that allows to access to captured
scope - we'd need to special-case $this there. Etc...
We shouldn't access local variables in irregular way.
This irregularity makes extract() and parse_str() to be special and they
require special handling.
See Nikita's RFC https://wiki.php.net/rfc/forbid_dynamic_scope_introspection

If we remove this checks, we go back to 7.0 behavior - we create a local
variable $this, that has nothing in common with real internal $this
stored in EX(This).
That's not good, but maybe we could make them agree in some way?
What do you mean? Change the real $this to something else in the middle
of the method???

In most cases it doesn't show $this in 7.0.
Right. But you're changing 7.0 behavior anyway?

Right. And I don't see reason to show $this in get_defined_vars(),
because it's special, and not really a local variable.

Thanks. Dmitry,

7 years ago by Fleshgrinder — view source

unread

https://wiki.php.net/rfc/this_var

Hi Dmitry,

could you extend the RFC with an additional section that mentions to
update corresponding manual pages, e.g.:

https://secure.php.net/language.variables.basics

There is a regular expression on that page that looks like the following
and is often referred to by people explaining variable names in PHP:

[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*

I would propose to update this to the following more complete PCRE:

/^$?(?!this)[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*$/D

@nikic this is also important for your RFC regarding empty variable
names because the PCRE would need to be updated once more too:

/^$?(?!this)[a-zA-Z_\x7f-\xff]?[a-zA-Z0-9_\x7f-\xff]*$/D

Of course the sentence preceding the regular expression would also
require an update.

There might be more pages that I am not aware of but we could ask
someone from the documentation team to help us here. The above one is
definitely the most important one and it should imho be included in the RFC.

--
Richard "Fleshgrinder" Fussenegger

7 years ago by Dmitry Stogov — view source

unread

good point. I'll update RFC and patch to support extract() and get_defined_vars().

7 years ago by James Gilliland — view source

unread

In the section "Disable ability to re-assign $this indirectly through $$"
it looks like there is a typo. It only makes sense if you mean $$a instead
of $aa.

7 years ago by Dmitry Stogov — view source

unread

Hi Richard,

$this is still confirm to variable syntax. It's just a special variable.
I think, we should keep lexical rules unchanged.

Thanks. Dmitry.

7 years ago by Fleshgrinder — view source

unread

Hi Richard,

$this is still confirm to variable syntax. It's just a special variable.
I think, we should keep lexical rules unchanged.

The page is about user assignable variable names. If I understand it
correct we cannot to the following anymore in userland:

$this = 'my value';

Hence $this is correct to lexical rules but not in the context of
variables that I can use to assign something too. Hence the change of
the manual page. I did not say anything about lexical changes.

Note well that the above is already not possible in many situations:

php -r '$this = "my value";'

Fatal error: Cannot re-assign $this in Command line code on line 1

TL;DR $this does conform to syntax but not to basic PHP userland rules
for variable naming (what the manual page is about).

--
Richard "Fleshgrinder" Fussenegger

7 years ago by Christoph Becker — view source

unread

$this is still confirm to variable syntax. It's just a special variable.
I think, we should keep lexical rules unchanged.

TL;DR $this does conform to syntax but not to basic PHP userland rules
for variable naming (what the manual page is about).

I agree with Dmitry here. While the page is about variables, the
paragraph is about variable names, and it is already noted there that:

| $this is a special variable that can't be assigned

In other sections of the manual, $this is described as
pseudo-variable. However, it is still a variable, even though it
can't be assigned to – I think of it as read-only (final) variable.
Hence, it shouldn't be excluded from the valid variable names.

--
Christoph M. Becker

7 years ago by Dmitry Stogov — view source

unread

changing "$this" into "this" is not an option. This would break 90% of PHP code :)

From: Marc Bennewitz dev@mabe.berlin
Sent: Tuesday, May 24, 2016 10:21:02 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Fix inconsistent behavior of $this variable

I'm curious, what is it about $this that makes it special in the first
place? Can't it be a normal local variable that happens to already be
assigned at the start of a method?

There are a few things that take advantage of its specialness, e.g.

binding a closure to an object changes the meaning of $this in a way
very different from assigning it into scope with "use($this)"

a method declared static can detect and throw errors on anything
referencing $this

when calling parent::foo() from an instance method, the value of
$this needs to be set appropriately on the new method; being able to
reassign $this could lead to some odd behaviour there

Python's approach is certainly valid, and leads to some different
useful properties, I'm sure, but it's a very different design, not
just a more relaxed attitude to assignment.

I know it would be a huge BC break but for me it sounds more "right" and
could also be introduced
in parallel to $this for a long long time but without a lot of
overplayed code for $this.

Thanks,
Marc

Regadrds,