Re: [RFC - discussion] __toArray()
| From: | Marco Pivetta | Date: | Tue, 04 Feb 2020 14:23:35 +0000 |
| Subject: | Re: [RFC - discussion] __toArray() | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-108386@lists.php.net to get a copy of this message | ||
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.
>