On Wed, 6 Apr 2022 at 14:37, Guilliam Xavier <guilliam.xav...@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->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. Regards, -- Rowan Tommins [IMSoP]
