Internals,
Part 2 of the undefined behaviour improvements, this time focusing on
properties.https://wiki.php.net/rfc/undefined_property_error_promotion
This RFC draws heavily from the just passed undefined variables error
promotion RFC, and is intended to compliment both it, and the 8.2
Deprecate Dynamic Properties RFC.The arguments in favour are the same as the last one, reading things
which don't exist will often lead to the program entering an unintended
state, and is likely the result of a programming error.There is a difference though that we do explicitly provide an object
that is designed to be dynamic, and that is stdClass which is the
typical output from json_decode and array to object casts.I would expect we might want to discuss special-casing the accessing of
properties on stdClass and leave them as a warning.However, I personally think that for the sake of consistency we should
make undefined properties throw across the board, including stdClass.We already have fully backwards compatible mechanisms built into the
language (isset, empty, null coalesce, property_exists) to safely handle
cases of the property not being defined, even on objects that do not
have a fixed structure.I was originally going to include a section for discussion about
potentially using AllowDynamicProperties to pull double duty, allowing
reads without an error as well, but I do not believe that would be in
the best interests of the language, and so removed it.Mark Randall
--
To unsubscribe, visit: https://www.php.net/unsub.php
Hey Mark,
This looks awesome!
FWIW, I'd like to see option 2 only because of custom serializers
and/or object proxies and also because:
This RFC proposes that accessing an undefined property is rendered illegal behaviour
StdClass has no defined properties and thus would always throw. But
I also guess it depends on what you define "undefined" as. Does simply
doing $obj->prop "define" the property "prop"?
-- Rob
On Wed, Apr 6, 2022 at 2:37 PM Robert Landers landers.robert@gmail.com
wrote:
FWIW, I'd like to see option 2 only because of custom serializers
and/or object proxies and also because:This RFC proposes that accessing an undefined property is rendered
illegal behaviourStdClass has no defined properties and thus would always throw. But
I also guess it depends on what you define "undefined" as. Does simply
doing $obj->prop "define" the property "prop"?
The RFC doesn't change the current meaning of "undefined" (or "defined", or
"declared"...), just proposes to throw an Error (while it currently
triggers an E_WARNING).
First sentence of the introduction: "Undefined properties are those that
have not yet been defined either by the presence of a property declaration,
or by adding them to the properties hashmap through direct assignment, or
by having them assigned by an internal function such as json_decode."
$obj->prop alone doesn't define the property "prop", but $obj->prop = whatever does.
Regards,
--
Guilliam Xavier
On Wed, 6 Apr 2022 at 14:37, Guilliam Xavier guilliam.xavier@gmail.com
wrote:
First sentence of the introduction: "Undefined properties are those that
have not yet been defined either by the presence of a property declaration,
or by adding them to the properties hashmap through direct assignment, or
by having them assigned by an internal function such as json_decode."
$obj->propalone doesn't define the property "prop", but$obj->prop = whateverdoes.
I missed the implications of this at first too; maybe some examples would
be useful?
The more I think about it, the more different scenarios there are here,
some of which are more obvious than others:
- Reading a property that is not listed in a class definition, and has
never been written to - Reading a property that is not listed in a class definition, but HAS
previously been assigned to - Reading a property that IS listed in the class definition, but has been
"removed" with unset() - Reading a property that is listed in the class definition, but has no
default value, and has never been assigned
For each of these, we could consider the behaviour:
a) on an instance of stdClass
b) on a class with the AllowDynamicProperties attribute
c) on a class with neither
Of these:
- Case 1 seems like the most obviously in scope of the proposal.
- Case 2c would be impossible, because assigning to the property would
already have given an error. 2a and 2b are the open question that's already
been mentioned. - Cases 3 and 4 already throw an error for typed properties, which track
the special "uninitialised" state, but for untyped properties case 4 does
not currently raise a Warning.
As with the previous RFC, I think this should be an opportunity to define
the consistent behaviour we want, rather than just looking at what previous
versions did.
Regards,
Rowan Tommins
[IMSoP]