Re: [VOTE] Undefined Property Error Promotion
| From: | Larry Garfield | Date: | Thu, 28 Apr 2022 16:59:53 +0000 |
| Subject: | Re: [VOTE] Undefined Property Error Promotion | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-117644@lists.php.net to get a copy of this message | ||
On Thu, Apr 28, 2022, at 9:05 AM, Côme Chilliet wrote:
> Le lundi 25 avril 2022, 18:19:33 CEST Rowan Tommins a écrit :
>> 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)'
>
> I second that it would make sense for an untyped property to behave the
> same as a typed one with type mixed.
> Getting a behavior change by adding a mixed typing to an untyped
> property is highly unexpected.
>
> Côme
Changing the logic so that untyped properties are essentially a shorthand for typing mixed (like
no-visibility is a shorthand for public) could be beneficial in the long run. It would be more
consistent, and with the robustness around null-based tooling now that also works with undefined, it
would probably not be too drastic a break if people knew to prepare for it (vis, happen in 9). I
could get behind that, but that should be its own separate RFC.
--Larry Garfield