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. > 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 could special case nullable, but then it's an extra rule to learn > > beyond "typed = needs to be initialized". > > I'm more inclined to the opposite: if reading an "undefined" property is > going to be an error, maybe reading an "uninitialized" one should be > too, even if you don't declare a type for it. > Are you proposing to deprecate the implicit `= null` default initializer for untyped properties? > And maybe we should think about exactly what unset() means, and which > error you're going to get after you use it - is the property "undefined" > or "uninitialized"? Currently, an untyped property becomes "undefined", > as though it never existed; but a typed property is still on the object, > but "uninitialized". Yet either way, assigning a new value brings back > the declared property, not a dynamic one with the same name: > https://3v4l.org/nClNs > 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? * "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." Regards, -- Guilliam Xavier
