Re: [PHP-DEV] [RFC] Undefined Property Error Promotion
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
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
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]
[PHP-DEV] MySQLi Execute Query RFC
Hi, Kamil has been working on a proof of concept for a `mysqli_execute_query($sql, $params)` function, and I've written up a draft RFC for it: https://wiki.php.net/rfc/mysqli_execute_query It's continuing the work Kamil has done with the "mysqli bind in execute" RFC [1], to make parameterised MySQLi queries even easier, by creating a single function that takes the SQL and Parameters and returns mysqli_result|false. While this can be implemented in userland, the focus is on trying to make parameterised queries as easy as possible, so developers are less less likely to use risky escaping. Craig [1] https://wiki.php.net/rfc/mysqli_bind_in_execute
Re: [PHP-DEV] [RFC] Undefined Property Error Promotion
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
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
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
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
[PHP-DEV] [RFC] Undefined Property Error Promotion
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
Re: [PHP-DEV] Reflection changes due to allow null + false as standalone types RFC
Hi George, > https://github.com/php/php-src/pull/7546#discussion_r837900447 Thanks for asking (even if voted). On Tue, Apr 5, 2022 at 2:01 PM Marco Pivetta wrote: > Probably best with consistency? > > > - Ignore the Reflection changes of the RFC and align the union type with > the current behaviour > > This one, specifically. > I agree with Marco (who I know works on reflection-related projects). To expand a bit: when reading the RFC, "the notable exception that `null|false` will produce a ReflectionUnionType instead of a ReflectionNamedType contrary to other `null|T` types" seemed legit because - `T|false` currently always produces a ReflectionUnionType - `null|T` producing a ReflectionNamedType (like `?T`) was only decided *for backwards-compatibility reasons* [ https://wiki.php.net/rfc/union_types_v2#reflection] (moreover the initial RFC [https://wiki.php.net/rfc/null-standalone-type] only proposed standalone `null`, not `false`, so didn't allow `?false`) but now looking at the implementation, I don't like the special casing. Regards, -- Guilliam Xavier
