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. >> > >> > >> > -- >> > regards, >> > >> > Kalle Sommer Nielsen >> > ka...@php.net >> > >> > >
