FAQ
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.

Search Discussions

  • Nikita Popov at May 23, 2016 at 8:46 pm

    On Mon, May 23, 2016 at 10:24 PM, Dmitry Stogov 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.
    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
  • Dmitry Stogov at May 23, 2016 at 9:28 pm
    good point. I'll update RFC and patch to support extract() and get_defined_vars().

    ________________________________
    From: Nikita Popov <nikita.ppv@gmail.com>
    Sent: Monday, May 23, 2016 11:46:35 PM
    To: Dmitry Stogov
    Cc: internals; Nikita Popov; Bob Weinand; Xinchen Hui
    Subject: Re: [PHP-DEV] [RFC] Fix inconsistent behavior of $this variable

    On Mon, May 23, 2016 at 10:24 PM, Dmitry Stogov 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.

    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
  • James Gilliland at May 23, 2016 at 9:49 pm
    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.
  • Xinchen Hui at May 24, 2016 at 2:30 am
    Hey:


    On Tue, May 24, 2016 at 4:24 AM, Dmitry Stogov 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

    thanks
  • Dmitry Stogov at May 24, 2016 at 7:14 am

    On 05/24/2016 05:29 AM, Xinchen Hui wrote:
    Hey:



    On Tue, May 24, 2016 at 4:24 AM, Dmitry Stogov 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/
  • Jesse Schalken at May 24, 2016 at 5:45 am
    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?
    On Tue, May 24, 2016 at 6:24 AM, Dmitry Stogov 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.
  • Dmitry Stogov at May 24, 2016 at 7:18 am

    On 05/24/2016 08:45 AM, Jesse Schalken wrote:
    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 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.
  • Jesse Schalken at May 24, 2016 at 7:25 am

    On Tue, May 24, 2016 at 5:18 PM, Dmitry Stogov wrote:

    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?
  • Yasuo Ohgaki at May 24, 2016 at 7:55 am
    Jesse,
    On Tue, May 24, 2016 at 4:25 PM, Jesse Schalken wrote:
    On Tue, May 24, 2016 at 5:18 PM, Dmitry Stogov wrote:

    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
  • Jesse Schalken at May 24, 2016 at 8:41 am

    On Tue, May 24, 2016 at 5:54 PM, Yasuo Ohgaki 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.

    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
  • Zeev Suraski at May 24, 2016 at 8:59 am

    -----Original Message-----
    From: 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 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
  • Rowan Collins at May 24, 2016 at 9:59 am

    On 24/05/2016 06:45, Jesse Schalken wrote:
    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]
  • Marc Bennewitz at May 24, 2016 at 7:21 pm

    On 05/24/2016 11:57 AM, Rowan Collins wrote:
    On 24/05/2016 06:45, Jesse Schalken wrote:
    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,
  • Rowan Collins at May 24, 2016 at 9:00 pm

    On 24/05/2016 20:21, Marc Bennewitz wrote:
    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]
  • Dmitry Stogov at May 31, 2016 at 4:42 pm
    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
    On 05/24/2016 11:57 AM, Rowan Collins wrote:
    On 24/05/2016 06:45, Jesse Schalken wrote:
    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,

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Stanislav Malyshev at May 24, 2016 at 6:54 am
    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:
    1. How static __call is a thing? That looks like something that makes no
    sense at all.
    2. Why get_defined_vars() shouldn't show $this?

    --
    Stas Malyshev
    smalyshev@gmail.com
  • Dmitry Stogov at May 24, 2016 at 7:34 am

    On 05/24/2016 09:54 AM, Stanislav Malyshev wrote:
    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:
    1. 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
    2. Why get_defined_vars() shouldn't show $this?
    In most cases it doesn't show $this in 7.0.

    Thanks. Dmitry.
  • Stanislav Malyshev at May 24, 2016 at 8:05 am
    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
  • Dmitry Stogov at May 24, 2016 at 8:23 am

    On 05/24/2016 11:04 AM, Stanislav Malyshev wrote:
    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,
  • Fleshgrinder at May 31, 2016 at 4:20 pm

    On 5/23/2016 10:24 PM, Dmitry Stogov wrote:
    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
  • Dmitry Stogov at May 31, 2016 at 4:39 pm
    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.


    ________________________________________
    From: Fleshgrinder <php@fleshgrinder.com>
    Sent: Tuesday, May 31, 2016 7:19:57 PM
    To: Dmitry Stogov; internals; Nikita Popov
    Subject: Re: [PHP-DEV] [RFC] Fix inconsistent behavior of $this variable
    On 5/23/2016 10:24 PM, Dmitry Stogov wrote:
    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
  • Fleshgrinder at May 31, 2016 at 4:55 pm

    On 5/31/2016 6:39 PM, Dmitry Stogov wrote:
    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
  • Christoph Becker at May 31, 2016 at 5:22 pm

    On 31.05.2016 at 18:55, Fleshgrinder wrote:
    On 5/31/2016 6:39 PM, Dmitry Stogov wrote:

    $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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedMay 23, '16 at 8:24p
activeMay 31, '16 at 5:22p
posts24
users12
websitephp.net

People

Translate

site design / logo © 2018 Grokbase