On Wed, 6 Apr 2022 at 14:37, Guilliam Xavier <guilliam.xav...@gmail.com>

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

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:

1) Reading a property that is not listed in a class definition, and has
never been written to
2) Reading a property that is not listed in a class definition, but HAS
previously been assigned to
3) Reading a property that IS listed in the class definition, but has been
"removed" with unset()
4) 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.

Rowan Tommins

Reply via email to