Re: [PHP-DEV] [RFC - discussion] __toArray()

This is only part of a thread. view whole thread
  108379
February 4, 2020 13:43 ocramius@gmail.com (Marco Pivetta)
On Tue, Feb 4, 2020, 14:36 Benjamin Eberlei <kontakt@beberlei.de> wrote:

> > > On Tue, Feb 4, 2020 at 2:10 PM Marco Pivetta <ocramius@gmail.com> wrote: > >> Linking (again) previous discussions: >> https://externals.io/message/98539#98539 >> >> `__toArray` as a magic function call when `(array)` cast happen is a bad >> idea: it is a BC break, and it removes one of the very few interactions >> (with objects) that didn't cause any side-effects ( >> https://externals.io/message/98539#98545, >> https://externals.io/message/98539#98567) >> > > I think we can't classify it as BC break, because no existing code > implements __toArray at the moment, and hence it will not fail when this > feature is introduced and code gets upgraded to newer versions. >
It is a BC break because it changes the semantic of `(array) $object`: the operation is no longer stable between two versions of the language. Code relying on `(array)` behaviour (stable) requires additional reflection wrappers to check if `$object` is **not** implementing `__toArray`, and then the operation can be safely used (or an exception is to be thrown). You can most certainly make a new operation, such as `(toArray) $object`: the cast operator is new and isn't changing any existing behaviour.
  108383
February 4, 2020 13:50 norbert@aimeos.com (Aimeos | Norbert Sendetzky)
Am 04.02.20 um 14:43 schrieb Marco Pivetta:
>> I think we can't classify it as BC break, because no existing code >> implements __toArray at the moment, and hence it will not fail when this >> feature is introduced and code gets upgraded to newer versions. > > It is a BC break because it changes the semantic of `(array) $object`: the > operation is no longer stable between two versions of the language.
It wouldn't be a BC breaking change if `(array) $object` works like before when __toArray() isn't implemented by an object. As nobody should have implemented __toArray() because it's a reserved name for magic methods, we should be fine.
  108386
February 4, 2020 14:23 ocramius@gmail.com (Marco Pivetta)
On Tue, Feb 4, 2020, 14:50 Aimeos | Norbert Sendetzky <norbert@aimeos.com>
wrote:

> Am 04.02.20 um 14:43 schrieb Marco Pivetta: > >> I think we can't classify it as BC break, because no existing code > >> implements __toArray at the moment, and hence it will not fail when this > >> feature is introduced and code gets upgraded to newer versions. > > > > It is a BC break because it changes the semantic of `(array) $object`: > the > > operation is no longer stable between two versions of the language. > > It wouldn't be a BC breaking change if `(array) $object` works like > before when __toArray() isn't implemented by an object. As nobody should > have implemented __toArray() because it's a reserved name for magic > methods, we should be fine. >
The operation in question, when seen by its signature, is: (array) :: object FieldTypes -> Map String FieldTypes The proposed RFC changes this to (pardon the weird union type: my type-fu is not that advanced): (array) :: (FieldTypes|IO ToArrayTypes a) => object a -> Map String a This changes the return type of a very much pure function (even makes it non-pure: fun), and is a very, very, very clear BC break.
>
  108390
February 4, 2020 15:01 chasepeeler@gmail.com (Chase Peeler)
On Tue, Feb 4, 2020 at 9:23 AM Marco Pivetta <ocramius@gmail.com> wrote:

> On Tue, Feb 4, 2020, 14:50 Aimeos | Norbert Sendetzky <norbert@aimeos.com> > wrote: > > > Am 04.02.20 um 14:43 schrieb Marco Pivetta: > > >> I think we can't classify it as BC break, because no existing code > > >> implements __toArray at the moment, and hence it will not fail when > this > > >> feature is introduced and code gets upgraded to newer versions. > > > > > > It is a BC break because it changes the semantic of `(array) $object`: > > the > > > operation is no longer stable between two versions of the language. > > > > It wouldn't be a BC breaking change if `(array) $object` works like > > before when __toArray() isn't implemented by an object. As nobody should > > have implemented __toArray() because it's a reserved name for magic > > methods, we should be fine. > > > > The operation in question, when seen by its signature, is: > > (array) :: object FieldTypes -> Map String FieldTypes > > The proposed RFC changes this to (pardon the weird union type: my type-fu > is not that advanced): > > (array) :: (FieldTypes|IO ToArrayTypes a) => object a -> Map String a > > This changes the return type of a very much pure function (even makes it > non-pure: fun), and is a very, very, very clear BC break. > > > > I think we all know that I'm very big on avoiding BC breaks. I personally
don't see this as a BC break, though. At least not one with PHP. Right now, behavior when casting things to an array is like so: (array)$scalar ==> [$scalar] (array)$array ==> $array (array)$object ==> [$prop1=>$val1, $prop2=>$val2, ...] So, assuming that right now I have the code: $x = new SomeThirdPartyArrayLikeObject(); //stuff $y = (array)$x; //$y ==> [$prop1=>$val1, $prop2 => $val2, ...] In a future version, in order to make that library more array-like, the following is added: public function __toArray(){ return [$this]; } Based on that, I'd argue that the BC break is with the library, not PHP. If the __toArray function is not implemented on that class, then nothing changes. The only way you'd get BC breaks with PHP itself is if core (and, arguably extension) classes started behaving differently when cast to an array. I'm personally in favor of anything that is going to allow us to create array-like objects that can be treated like arrays. I personally hate having to write: if(is_object($var)){ $x = [$var]; } else { $x = (array)$var; } No, the other question is whether we do it with a magic method, like __toArray() or an interface. I personally like magic methods, but, in the end I'm ambivalent on that. -- Chase Peeler chasepeeler@gmail.com
  108384
February 4, 2020 14:13 kontakt@beberlei.de (Benjamin Eberlei)
On Tue, Feb 4, 2020 at 2:43 PM Marco Pivetta <ocramius@gmail.com> wrote:

> > > On Tue, Feb 4, 2020, 14:36 Benjamin Eberlei <kontakt@beberlei.de> wrote: > >> >> >> On Tue, Feb 4, 2020 at 2:10 PM Marco Pivetta <ocramius@gmail.com> wrote: >> >>> Linking (again) previous discussions: >>> https://externals.io/message/98539#98539 >>> >>> `__toArray` as a magic function call when `(array)` cast happen is a bad >>> idea: it is a BC break, and it removes one of the very few interactions >>> (with objects) that didn't cause any side-effects ( >>> https://externals.io/message/98539#98545, >>> https://externals.io/message/98539#98567) >>> >> >> I think we can't classify it as BC break, because no existing code >> implements __toArray at the moment, and hence it will not fail when this >> feature is introduced and code gets upgraded to newer versions. >> > > It is a BC break because it changes the semantic of `(array) $object`: the > operation is no longer stable between two versions of the language. > > Code relying on `(array)` behaviour (stable) requires additional > reflection wrappers to check if `$object` is **not** implementing > `__toArray`, and then the operation can be safely used (or an exception is > to be thrown). > > You can most certainly make a new operation, such as `(toArray) $object`: > the cast operator is new and isn't changing any existing behaviour. >
I believe the definition of BC break is "can an existing code-base run on the new PHP version without changes" and here the answer is yes, since __toArray fn's are not used by any existing code bases. What you refer to is, can existing code work with new code using this feature, and then the answer is indeed no. But the same was true for example for typed properties, which also requires additional handling in most meta programming libraries, and many other new features that existing libraries needed to adapt to: namespaces, scalar type hints, return types, ....