> > Are you proposing to deprecate the implicit `= null` default initializer
> > for untyped properties?
> Yes.
> > 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?
> The issue is that for new users, saying "that's the historical
> behaviour, you just have to learn it" is not very helpful.
> > * "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."
> I think both you and Mark misunderstood my point in bringing this up -
> I'm not complaining about the ability to call unset(), I'm complaining
> that it behaves differently depending how the property was declared.
> 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)'

Understood (also https://3v4l.org/DgXJl ). Maybe start a new thread? (this
one is not shown on externals.io, only findable via search)

Guilliam Xavier

Reply via email to