Re: [PHP-DEV] [RFC] Undefined Property Error Promotion

2022-04-19 Thread Guilliam Xavier
On Sat, Apr 16, 2022 at 12:01 AM David Rodrigues 
wrote:

> > $foo[?'maynotexist'] // returns null and emits no warning
>
> In JS we have some like:
>
> foo['maynotexist']
> foo?.['maynotexist']
>
> In PHP could be:
>
> $foo['maynotexist']
> $foo?->['maynotexist']
>

You seem to be confusing two different things (in short, ?-> vs ->?):

  1. In PHP *too* we *already* have "*nullsafe* property access"
$objectThatMayBeNull?->property (but no "nullsafe array access"
$arrayThatMayBeNull?['key'], see
https://wiki.php.net/rfc/nullsafe_operator#future_scope) since PHP 8.0 (see
https://www.php.net/releases/8.0/en.php,
https://www.php.net/manual/en/migration80.new-features.php etc.)
  2. What may be proposed (in another RFC) is something like
$object->?propertyThatMayNotExist and/or $array[?'keyThatMayNotExist']
(call it e.g. "*lenient* property/array access"?) (JS is lenient by default)

But let's not deviate further.

Regards,

-- 
Guilliam Xavier


Re: [PHP-DEV] [RFC] Undefined Property Error Promotion

2022-04-15 Thread David Rodrigues
> $foo[?'maynotexist'] // returns null and emits no warning

In JS we have some like:

foo['maynotexist']
foo?.['maynotexist']

In PHP could be:

$foo['maynotexist']
$foo?->['maynotexist']

Atenciosamente,
David Rodrigues


Em sex., 15 de abr. de 2022 às 18:41, Mark Randall 
escreveu:

> On 06/04/2022 19:38, Larry Garfield wrote:
> > On the last point, regarding stdClass, I think the question is whether
> we want it to be consistent with classed object properties (throw) or with
> associative arrays (warnings).  stdClass is kind of an uncomfortable middle
> between those two.  I'm not sure which is better to align with, although I
> almost never use stdClass and tell others to avoid it as well so it doesn't
> really matter to me. :-)
>
>
> My preference is to treat it like any other property, but I am open to
> hearing additional comments on this.
>
> I'm not sure how much conversation we can expect on this one, if it
> remains quiet I intend to open the vote in a week or so.
>
> As a tangent, R11 has had some comments made about a better method for
> indicating which property / array keys are expected to be missing, such as:
>
> $foo[?'maynotexist'] // returns null and emits no warning
>
> Down the line this might allow us to fix up arrays as well, but that's a
> question for a different RFC.
>
> Mark Randall
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>


Re: [PHP-DEV] [RFC] Undefined Property Error Promotion

2022-04-15 Thread Mark Randall

On 06/04/2022 19:38, Larry Garfield wrote:

On the last point, regarding stdClass, I think the question is whether we want 
it to be consistent with classed object properties (throw) or with associative 
arrays (warnings).  stdClass is kind of an uncomfortable middle between those 
two.  I'm not sure which is better to align with, although I almost never use 
stdClass and tell others to avoid it as well so it doesn't really matter to me. 
:-)



My preference is to treat it like any other property, but I am open to 
hearing additional comments on this.


I'm not sure how much conversation we can expect on this one, if it 
remains quiet I intend to open the vote in a week or so.


As a tangent, R11 has had some comments made about a better method for 
indicating which property / array keys are expected to be missing, such as:


$foo[?'maynotexist'] // returns null and emits no warning

Down the line this might allow us to fix up arrays as well, but that's a 
question for a different RFC.


Mark Randall

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php



Re: [PHP-DEV] [RFC] Undefined Property Error Promotion

2022-04-06 Thread Larry Garfield
On Wed, Apr 6, 2022, at 7:03 AM, Mark Randall wrote:
> Internals,
>
> Part 2 of the undefined behaviour improvements, this time focusing on 
> properties.
>
> https://wiki.php.net/rfc/undefined_property_error_promotion
>
> This RFC draws heavily from the just passed undefined variables error 
> promotion RFC, and is intended to compliment both it, and the 8.2 
> Deprecate Dynamic Properties RFC.
>
> The arguments in favour are the same as the last one, reading things 
> which don't exist will often lead to the program entering an unintended 
> state, and is likely the result of a programming error.
>
> There is a difference though that we do explicitly provide an object 
> that is designed to be dynamic, and that is stdClass which is the 
> typical output from json_decode and array to object casts.
>
> I would expect we might want to discuss special-casing the accessing of 
> properties on stdClass and leave them as a warning.
>
> However, I personally think that for the sake of consistency we should 
> make undefined properties throw across the board, including stdClass.

I am overall in favor of this.

On the last point, regarding stdClass, I think the question is whether we want 
it to be consistent with classed object properties (throw) or with associative 
arrays (warnings).  stdClass is kind of an uncomfortable middle between those 
two.  I'm not sure which is better to align with, although I almost never use 
stdClass and tell others to avoid it as well so it doesn't really matter to me. 
:-)

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php



Re: [PHP-DEV] [RFC] Undefined Property Error Promotion

2022-04-06 Thread Mark Randall

On 06/04/2022 17:34, Marco Pivetta wrote:

Perhaps worth mentioning that magic methods keep working?


Good call.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php



Re: [PHP-DEV] [RFC] Undefined Property Error Promotion

2022-04-06 Thread Rowan Tommins
On Wed, 6 Apr 2022 at 14:37, Guilliam Xavier 
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]


Re: [PHP-DEV] [RFC] Undefined Property Error Promotion

2022-04-06 Thread Marco Pivetta
Hey Mark,


On Wed, 6 Apr 2022 at 14:04, Mark Randall  wrote:

> Internals,
>
> Part 2 of the undefined behaviour improvements, this time focusing on
> properties.
>
> https://wiki.php.net/rfc/undefined_property_error_promotion
>
> This RFC draws heavily from the just passed undefined variables error
> promotion RFC, and is intended to compliment both it, and the 8.2
> Deprecate Dynamic Properties RFC.
>
> The arguments in favour are the same as the last one, reading things
> which don't exist will often lead to the program entering an unintended
> state, and is likely the result of a programming error.
>
> There is a difference though that we do explicitly provide an object
> that is designed to be dynamic, and that is stdClass which is the
> typical output from json_decode and array to object casts.
>
> I would expect we might want to discuss special-casing the accessing of
> properties on stdClass and leave them as a warning.
>
> However, I personally think that for the sake of consistency we should
> make undefined properties throw across the board, including stdClass.
>
> We already have fully backwards compatible mechanisms built into the
> language (isset, empty, null coalesce, property_exists) to safely handle
> cases of the property not being defined, even on objects that do not
> have a fixed structure.
>
> I was originally going to include a section for discussion about
> potentially using AllowDynamicProperties to pull double duty, allowing
> reads without an error as well, but I do not believe that would be in
> the best interests of the language, and so removed it.
>
> Mark Randall
>


Perhaps worth mentioning that magic methods keep working?

Marco Pivetta

https://twitter.com/Ocramius

https://ocramius.github.io/


Re: [PHP-DEV] [RFC] Undefined Property Error Promotion

2022-04-06 Thread Guilliam Xavier
On Wed, Apr 6, 2022 at 2:37 PM Robert Landers 
wrote:

>
> FWIW, I'd like to see option 2 only because of custom serializers
> and/or object proxies and also because:
>
> > This RFC proposes that accessing an undefined property is rendered
> illegal behaviour
>
> StdClass has *no* defined properties and thus would always throw. But
> I also guess it depends on what you define "undefined" as. Does simply
> doing $obj->prop "define" the property "prop"?
>

The RFC doesn't change the current meaning of "undefined" (or "defined", or
"declared"...), just proposes to throw an Error (while it currently
triggers an E_WARNING).
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.

Regards,

-- 
Guilliam Xavier


Re: [PHP-DEV] [RFC] Undefined Property Error Promotion

2022-04-06 Thread Guilliam Xavier
Hi Mark,

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

[note: the RFC Date has a +1 on the year]

I'm in favor for "fixed" classes (with all properties declared and no
`__get()` magic method),
but somewhat mixed for `stdClass`: as you said, it can come from a
`json_decode()` by default or an `(object)$array` cast, and is kind of
"interchangeable" with `array` (which can come from a `json_decode()` with
`associative: true` / `flags: JSON_OBJECT_AS_ARRAY` or an `(array)$object`
cast);
as such, I wonder if it wouldn't make more sense to rather handle undefined
properties *on stdClass* together with undefined *array keys*?
(the reasoning could even be extended to classes annotated with the
`#[AllowDynamicProperties]` attribute...)

Regards,

-- 
Guilliam Xavier


Re: [PHP-DEV] [RFC] Undefined Property Error Promotion

2022-04-06 Thread Robert Landers
On Wed, Apr 6, 2022 at 2:04 PM Mark Randall  wrote:
>
> Internals,
>
> Part 2 of the undefined behaviour improvements, this time focusing on
> properties.
>
> https://wiki.php.net/rfc/undefined_property_error_promotion
>
> This RFC draws heavily from the just passed undefined variables error
> promotion RFC, and is intended to compliment both it, and the 8.2
> Deprecate Dynamic Properties RFC.
>
> The arguments in favour are the same as the last one, reading things
> which don't exist will often lead to the program entering an unintended
> state, and is likely the result of a programming error.
>
> There is a difference though that we do explicitly provide an object
> that is designed to be dynamic, and that is stdClass which is the
> typical output from json_decode and array to object casts.
>
> I would expect we might want to discuss special-casing the accessing of
> properties on stdClass and leave them as a warning.
>
> However, I personally think that for the sake of consistency we should
> make undefined properties throw across the board, including stdClass.
>
> We already have fully backwards compatible mechanisms built into the
> language (isset, empty, null coalesce, property_exists) to safely handle
> cases of the property not being defined, even on objects that do not
> have a fixed structure.
>
> I was originally going to include a section for discussion about
> potentially using AllowDynamicProperties to pull double duty, allowing
> reads without an error as well, but I do not believe that would be in
> the best interests of the language, and so removed it.
>
> Mark Randall
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

Hey Mark,

This looks awesome!

FWIW, I'd like to see option 2 only because of custom serializers
and/or object proxies and also because:

> This RFC proposes that accessing an undefined property is rendered illegal 
> behaviour

StdClass has *no* defined properties and thus would always throw. But
I also guess it depends on what you define "undefined" as. Does simply
doing $obj->prop "define" the property "prop"?

-- Rob

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php