Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117600
Message-ID: <2bf2433e-2a4d-7523-7633-0e67a22a0c26@gmail.com>
Date: Mon, 25 Apr 2022 17:19:33 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.0
Content-Language: en-GB
To: internals@lists.php.net
References: <6261d073.1c69fb81.a42c.d7cfSMTPIN_ADDED_MISSING@mx.google.com>
 <CALKiJKpFGUJL8jNYaEv6rRaj9q_FVBcwmr_iJtGq2gjDdHxA4Q@mail.gmail.com>
 <6262e219.1c69fb81.f1cd4.6ff5SMTPIN_ADDED_MISSING@mx.google.com>
 <eaacd2a9-1ff8-1e5a-4028-e0df9172fd4b@gmail.com>
 <6263147d.1c69fb81.c372a.2e76SMTPIN_ADDED_MISSING@mx.google.com>
 <2fcee325-9ac1-8ad4-f55b-a0627c53a445@gmail.com>
 <CAC5V6gg3cCT_ps5N1z-R2zeuejNcAiThdo1=ZvnxNpJ_ijz16g@mail.gmail.com>
In-Reply-To: <CAC5V6gg3cCT_ps5N1z-R2zeuejNcAiThdo1=ZvnxNpJ_ijz16g@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [VOTE] Undefined Property Error Promotion
From: rowan.collins@gmail.com (Rowan Tommins)

On 25/04/2022 12:24, Guilliam Xavier wrote:
> Hi Rowan,
>
> (...) Also, there's this non-standard class called
>> "stdClass", which unlike standard classes, you can read and write any
>> property you like without declaring it,
>
> Better reordered "write and read" I think. Yes, like associative arrays,
> stdClass is "dynamic" by design.


Indeed, and if that was the only exception, it would be reasonable; it's 
when you pile it on top of all the other rules that it starts making 
people sad.


>> and even if you use unset(),
>> you'll never get an error.
>>
> That's not true, e.g. given `$o = (object)['foo' => 1]; $o->bar = 2;` then
> `unset($o->foo, $o->bar);`, trying to read `$o->foo` or `$o->bar` will both
> cause an error (like for `$o->qux`); or I'm misunderstanding you?


You're right, I was mis-remembering; the RFC explicitly says that this 
will error.


> Are you proposing to deprecate the implicit `= null` default initializer
> for untyped properties?


Yes.



> Thanks for the recap. For untyped properties, that's the historical
> behavior. For typed properties, that's explained in
> https://wiki.php.net/rfc/typed_properties_v2#uninitialized_and_unset_properties
> *. What's the issue?


The issue is that for new users, saying "that's the historical 
behaviour, you just have to learn it" is not very helpful.


> * "If a typed property is `unset()`, then it returns to the uninitialized
> state. While we would love to remove support for the unsetting of
> properties, this functionality is currently used for lazy initialization by
> Doctrine, in combination with the functionality described in the following
> section."


I think both you and Mark misunderstood my point in bringing this up - 
I'm not complaining about the ability to call unset(), I'm complaining 
that it behaves differently depending how the property was declared.

Look at how the untyped property behaves in this example: 
https://3v4l.org/nClNs The property disappears from var_dump(), but is 
not actually deleted from the object, as seen by it still being private 
when assigned a new value. Given that we have the magic "uninitialized" 
state, and we're proposing to make reading an unset property an error, 
it would make more sense for it to show as '["untyped":"Foo":private] => 
uninitialized(mixed)'


Regards,

-- 
Rowan Tommins
[IMSoP]