Correct: passing an object that implements `__toArray()` to an API that uses an `(array)` cast internally will break or misbehave, if this feature is added to the language.
On 16 Mar 2017 12:27 a.m., "Ryan Pallas" <derokor...@gmail.com> wrote: > > > On Mar 15, 2017 5:03 PM, "Marco Pivetta" <ocram...@gmail.com> wrote: > > Hi Ryan, > > I'm top-posting because I'm writing from a phone. I always do and I also > stopped caring for top-posters myself because it's fairly normal, plus > modern email clients deal with it. If I can write a damn mail from a phone > keyboard because I don't have any better right now, then you can probably > use the scroll wheel once on your pc too. > > I'll just say this: I'm also on a mobile device. Don't make assumptions. > > > The BC break applies to API that accepts `object` (any object). Such API > is common in library code in frameworks, data-mappers, etc. > > Such code would not work anymore for cases where the magic method is > implemented, adding either exceptions (forcing a library-level BC break) or > simply by causing the existing stable versions of these libs to be > incompatible with newer php versions. > > > I must misunderstand what constitutes an BC break. I thought a BC break > was when identical code produced different results. But you're saying its a > break because someone could change their code to use a new feature and > break their use of your library? > > > > > On 15 Mar 2017 11:57 p.m., "Ryan Pallas" <derokor...@gmail.com> wrote: > > > > On Mar 15, 2017 16:40, "Marco Pivetta" <ocram...@gmail.com> wrote: > > Which is precisely the BC break: such a library would now throw an > exception "unsupported class X" when `__toString` is implemented. Also, > such a library would break silently when this feature is implemented. > > Much like the already very broken `__debugInfo()`, this automatic > type-cast is a giga-Joule footgun. > > > First please stop top posting. > > Second bc means that if no code changes no functionality is changed. > That's exactly what we're talking about. If the class doesn't change > neither does the functionality. So unless classes already have __toArray > they will not change in behaviour. > > As pointed out in answer to my question earlier a class with no code > change would see no change in casting behaviour. Only if new method is > implemented will behaviour change. How does that not maintain bc? > > > On 15 Mar 2017 11:36 p.m., "Ryan Pallas" <derokor...@gmail.com> wrote: > >> >> >> On Wed, Mar 15, 2017 at 4:33 PM, Marco Pivetta <ocram...@gmail.com> >> wrote: >> >>> It's the only way to distinguish between set and unset properties. Also >>> the >>> only way to get all properties from an instance of an inheritance tree. >> >> Also, it's covered by tests that were explicitly added to prevent >>> regressions on this. >>> >>> Same as all similar discussions before this one: need an alternative way >>> to >>> do things before proposing a BC break. >>> >>> >> As mentioned in previous mails - the intent isn't to change existing >> behaviour, but to provide a way for a class to override the default >> behaviour. As long as those classes you are casting to array don't >> implement __toArray they will behave exactly as they always have. The only >> concern then, is that you might be relying on a library to not implement >> that function on a class you are casting. >> >> >>> On 15 Mar 2017 11:27 p.m., "Kalle Sommer Nielsen" <ka...@php.net> wrote: >>> >>> > Hi >>> > >>> > 2017-03-15 21:41 GMT+01:00 Marco Pivetta <ocram...@gmail.com>: >>> > > This is a BC break due to the fact that the `(array)` cast is used to >>> > > extract property information from private properties in library code. >>> >> > >>> > Yep, but then again that is more of an >>> > undocumented-not-really-supported case afair, if anything then >>> > Reflection should have the APIs to officially allow that, although I >>> > am still skeptic of this. >>> >> Does it not through get properties? > > > >>> > >>> > -- >>> > regards, >>> > >>> > Kalle Sommer Nielsen >>> > ka...@php.net >>> > >>> >> >> > > >
