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
>> >
>>
>
>

Reply via email to