[VOTE] Undefined Property Error Promotion

3 years ago by Rowan Tommins — view source — reply

unread

Internals,

I have now opened voting on Undefined Property Error Promotion.

https://wiki.php.net/rfc/undefined_property_error_promotion

As with your previous RFC, I approve of this in principle, but am
frustrated how little time has been spent considering the edge cases, such
as the ones I mentioned here: https://externals.io/message/117487#117487

It seems to me that we've got an increasingly complicated set of states a
property can be in, depending on whether it's been declared with a type,
without one, or not at all; whether it's had a value assigned to it;
whether it's been unset; etc. If I am struggling to follow the distinctions
between "declared", "defined", "initialised", "dynamic", "nullable" etc,
how will users who start with PHP 9.0 understand why some situations
produce errors and others do not?

Regards,

Rowan Tommins
[IMSoP]

3 years ago by Mark Randall — view source — reply

unread

As with your previous RFC, I approve of this in principle, but am
frustrated how little time has been spent considering the edge cases, such
as the ones I mentioned here: https://externals.io/message/117487#117487

Accessing an unset property, which currently emits a warning, will
instead throw an Error.

If a property has already been written to via some mechanism, then the
property exists and this RFC does not apply, no warning or error should
be expected. It's a different responsibility to handle the guards
against writing to one which has not been defined
(AllowDynamicProperties RFC).

Re: Case 4, an untyped property without its own initializer is
effectively defaulted to null.

3 years ago by Rowan Tommins — view source — reply

unread

Accessing an unset property, which currently emits a warning, will
instead throw an Error.

[...]

Re: Case 4, an untyped property without its own initializer is
effectively defaulted to null.

Imagine you're a new user, learning PHP 9.0, and learning that "public
$foo" defaults to null; and if you call unset(), it's deleted from the
object, and then accessing it is an error. But then you change it to
"public ?string $foo" and it doesn't default to null, even though it's
nullable, and accessing it will give you a different error; and calling
unset() on that doesn't delete it from the object, but does mean you get
an error reading it. 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, and even if you use unset(),
you'll never get an error.

Do you not have even a little bit of hope that we could make that less
confusing, since we're breaking everyone's old code anyway?

Regards,

--
Rowan Tommins
[IMSoP]

3 years ago by Mark Randall — view source — reply

unread

Do you not have even a little bit of hope that we could make that less
confusing, since we're breaking everyone's old code anyway?

I seem to remember we had a discussion years ago about deleting unset on
properties, but it was being used for a very popular proxy manager to
force them to be routed to __get.

The rule that anything typed must be initialized, nullable or not, is
clearish enough. You could special case nullable, but then it's an extra
rule to learn beyond "typed = needs to be initialized".

3 years ago by Rowan Tommins — view source — reply

unread

The rule that anything typed must be initialized, nullable or not, is
clearish enough.

It's "clear" in the sense of "it can be described in one sentence". It's
not at all "clear" in the sense of "makes any logical sense whatsoever".

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.

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

Regards,

--
Rowan Tommins
[IMSoP]

3 years ago by Guilliam Xavier — view source — reply

unread

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

3 years ago by Rowan Tommins — view source — reply

unread

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.

Indeed, and if that was the only exception, it would be reasonable; it's
when you pile it on top of all the other rules that it starts making
people sad.

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're right, I was mis-remembering; the RFC explicitly says that this
will error.

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)'

Regards,

--
Rowan Tommins
[IMSoP]

3 years ago by Guilliam Xavier — view source — reply

unread

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

3 years ago by come@chilliet.eu — view source — reply

unread

Le lundi 25 avril 2022, 18:19:33 CEST Rowan Tommins a écrit :

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)'

I second that it would make sense for an untyped property to behave the same as a typed one with type mixed.
Getting a behavior change by adding a mixed typing to an untyped property is highly unexpected.

Côme

3 years ago by Larry Garfield — view source — reply

unread

Le lundi 25 avril 2022, 18:19:33 CEST Rowan Tommins a écrit :

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)'

I second that it would make sense for an untyped property to behave the
same as a typed one with type mixed.
Getting a behavior change by adding a mixed typing to an untyped
property is highly unexpected.

Côme

Changing the logic so that untyped properties are essentially a shorthand for typing mixed (like no-visibility is a shorthand for public) could be beneficial in the long run. It would be more consistent, and with the robustness around null-based tooling now that also works with undefined, it would probably not be too drastic a break if people knew to prepare for it (vis, happen in 9). I could get behind that, but that should be its own separate RFC.

--Larry Garfield

3 years ago by Rowan Tommins — view source — reply

unread

Internals,

I have now opened voting on Undefined Property Error Promotion.

https://wiki.php.net/rfc/undefined_property_error_promotion

In case anyone missed it due to some messed-up mail headers, the thread
I intended to be a reply to this is here:
https://externals.io/message/117571

My position is that both this and the undefined variable RFC should have
been a review of functionality, not a blind copy and paste of Warnings
into Errors. Since I don't seem to have persuaded anyone else of this, I
will try to raise one or more follow-up RFCs trying to fill in the gaps.

Regards,

--
Rowan Tommins
[IMSoP]