Re: [PHP-DEV] Proposal for a RFC

[Marco Pivetta]

Hey Benjamin,

On Thu, Aug 29, 2019, 05:09 Benjamin Eberlei  wrote:

>
>
> On Sun, May 5, 2019 at 5:08 PM Nicolas Grekas 
> wrote:
>
>> Le sam. 4 mai 2019 à 18:37, Marco Pivetta  a écrit :
>>
>> > Hi Steven,
>> >
>> > As it currently stands, the array cast is the only operation capable of
>> > exposing object state without triggering any kind of access guards: it
>> is
>> > very much required for anything that works with reflection and typed
>> > properties, and possibly the only operation in PHP that operates on
>> state
>> > without some contraption intercepting its execution.
>> >
>> > It is also necessary to distinguish dynamic properties from declared
>> object
>> > state.
>> >
>> > For comparison, all of the following have side-effects due to the
>> > complexity of the language:
>> >
>> >  * isset()
>> >  * unset()
>> >  * property read
>> >  * property write
>> >  * ReflectionProperty#getValue()
>> >  * ReflectionProperty#setValue()
>> >
>> > Overall, this is problematic, and introduces more magic that I'd gladly
>> > avoid, in an endpoint used to work around all the engine magic (the only
>> > stable one so far).
>> >
>> > From my end, this sounds like a bad idea, because it removes one of the
>> > very very few referentially transparent guarantees (if not the only one,
>> > when dealing with objects) from the language.
>> >
>> > Greets,
>> >
>> > Marco
>> >
>>
>> I want to weight in with what Marco expressed. I have the very same
>> concerns and they are major ones for many use cases. Mine is VarDumper.
>>
>> Please don't do this the way it is described.
>>
>
> Because Steve asked for wiki access to work on an RFC for his proposal, I
> went back and re-read and just wanted to come in his support as I think it
> would be a great addition to the existing __magic functionality,
>
> I want to add a few more arguments why __toArray() should be added
> regardless of the objections from Marco & Nicolas:
>
> 1. PHP already has __debugInfo() which affects the behavior of var_dump()
> allowing users to control what gets exposed to it in a debugging context.
> This is new magic method would affect Symfony's VarDumper+ VarCloner in a
> similar consistent way that gives class owners back control of what gets
> exposed. One primary benefit of OOP is encapsulation and guarding against
> access of internal state from the outside, so it is questionable anyways
> why an idiomatic and simple to use syntax like (array) $object would expose
> internal state and a developer would have no means of preventing that.
>

__debugInfo is already arguably added complexity and debugging time for
those looking at a dump result and not understanding it. From my PoV, I'd
love to also see __debugInfo gone, since it only ever caused me to lose
hair.


> 2. Adding __toArray would not constitute a backwards compatibility break,
> because all existing code does not implement __toArray and would keep the
> same exact behavior.
>

It would break any code relying on current `(array)` semantics against the
general `object` type. Can certainly propose it for 8.x, and then we go on
a hunt for `(array)` casts, and disallowing them explicitly (cs, static
analysis).


> 3. You can't argue against the concept of magic methods overall by citing
> your own use case that is objectively an extremely magic use of the
> existing behavior of (array) $object itself. I can see a very good case to
> change (array) $object to return only public properties as part of the
> general push to cleanup inconsistent behavior in PHP 8. As Nikita
> mentioned, it might make sense to add a function that is specifically
> designed for your both use-cases instead and that would honestly make this
> part of the language cleaner in the end and we can get rid of this *
> protected and nullbyte private variable returning behavior once and for all.
>

It's fine to break this for 8.x, but I think 7.4 already has an added API
for this? Can't remember the name, but something about unmangled vars.


> 4. ReflectionProperty::getValue() does not trigger a guard clause if you
> call setAccessible(true) first, so I don't think the objection that this is
> the only way to access private data is true here. Correct me if I forgot an
> edge case that prevents this.
>

Guards are triggered for unset properties, even with reflection.


> 5. Arguments of API design that toSomethingString() is somehow "better"
> than using __toString() and therefore the addition of __toArray() is bad
> pit one paradigm (explicit OOP vs magic methods) and should be avoided in
> an RFC discussion. We are also not discussing to remove functions in PHP
> because we now have classes and methods and this falls into the same
> category. Its a subject design decision and shouldn't influence the
> expansion of an existing feature/paradigm that one doesn't use themselves.
>

I'd say that the paradigm is at the core of the discussion: magic calls are
some of the worst traps in the language, leading to monstrous 

Re: [PHP-DEV] Proposal for a RFC

[Benjamin Eberlei]

On Sun, May 5, 2019 at 5:08 PM Nicolas Grekas 
wrote:

> Le sam. 4 mai 2019 à 18:37, Marco Pivetta  a écrit :
>
> > Hi Steven,
> >
> > As it currently stands, the array cast is the only operation capable of
> > exposing object state without triggering any kind of access guards: it is
> > very much required for anything that works with reflection and typed
> > properties, and possibly the only operation in PHP that operates on state
> > without some contraption intercepting its execution.
> >
> > It is also necessary to distinguish dynamic properties from declared
> object
> > state.
> >
> > For comparison, all of the following have side-effects due to the
> > complexity of the language:
> >
> >  * isset()
> >  * unset()
> >  * property read
> >  * property write
> >  * ReflectionProperty#getValue()
> >  * ReflectionProperty#setValue()
> >
> > Overall, this is problematic, and introduces more magic that I'd gladly
> > avoid, in an endpoint used to work around all the engine magic (the only
> > stable one so far).
> >
> > From my end, this sounds like a bad idea, because it removes one of the
> > very very few referentially transparent guarantees (if not the only one,
> > when dealing with objects) from the language.
> >
> > Greets,
> >
> > Marco
> >
>
> I want to weight in with what Marco expressed. I have the very same
> concerns and they are major ones for many use cases. Mine is VarDumper.
>
> Please don't do this the way it is described.
>

Because Steve asked for wiki access to work on an RFC for his proposal, I
went back and re-read and just wanted to come in his support as I think it
would be a great addition to the existing __magic functionality,

I want to add a few more arguments why __toArray() should be added
regardless of the objections from Marco & Nicolas:

1. PHP already has __debugInfo() which affects the behavior of var_dump()
allowing users to control what gets exposed to it in a debugging context.
This is new magic method would affect Symfony's VarDumper+ VarCloner in a
similar consistent way that gives class owners back control of what gets
exposed. One primary benefit of OOP is encapsulation and guarding against
access of internal state from the outside, so it is questionable anyways
why an idiomatic and simple to use syntax like (array) $object would expose
internal state and a developer would have no means of preventing that.

2. Adding __toArray would not constitute a backwards compatibility break,
because all existing code does not implement __toArray and would keep the
same exact behavior.

3. You can't argue against the concept of magic methods overall by citing
your own use case that is objectively an extremely magic use of the
existing behavior of (array) $object itself. I can see a very good case to
change (array) $object to return only public properties as part of the
general push to cleanup inconsistent behavior in PHP 8. As Nikita
mentioned, it might make sense to add a function that is specifically
designed for your both use-cases instead and that would honestly make this
part of the language cleaner in the end and we can get rid of this *
protected and nullbyte private variable returning behavior once and for all.

4. ReflectionProperty::getValue() does not trigger a guard clause if you
call setAccessible(true) first, so I don't think the objection that this is
the only way to access private data is true here. Correct me if I forgot an
edge case that prevents this.

5. Arguments of API design that toSomethingString() is somehow "better"
than using __toString() and therefore the addition of __toArray() is bad
pit one paradigm (explicit OOP vs magic methods) and should be avoided in
an RFC discussion. We are also not discussing to remove functions in PHP
because we now have classes and methods and this falls into the same
category. Its a subject design decision and shouldn't influence the
expansion of an existing feature/paradigm that one doesn't use themselves.


> Nicolas
>

Re: [PHP-DEV] Proposal for a RFC

[Marco Pivetta]

On Thu, Jun 13, 2019 at 4:23 PM Steven Wade  wrote:

> > I guess that's what it comes down to, what *specific* use cases would
> this
> > feature be intended to help with? Is there some code of your own that
> > inspired you to propose it, or something you've seen publically that
> would
> > benefit from it?
>
> Originally, it was inspired by seeing Laravel's use of Arrayable as an
> interface and if something implements that, calling that class' `toArray()`
> method, and wishing that was built in so that frameworks didn't re-invent
> the wheel every time.
>

Interestingly, my work day today is spent mostly removing this kind of
behavior from a codebase riddled by it, replacing it with explicit
conversions where needed.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] Proposal for a RFC

[Steven Wade]

Apologies for the super late response:

> A recursive method would certainly have more value, because it actually
> does something more than translate one syntax to another. On the other
> hand, the use case that comes to mind is serialization, and we already have
> more specific methods and systems for that.

How could this new magic method be recursive? If it only works if you manually 
declare __toArray() in your class, wouldn't you then as the user be in charge 
of casting anything manually in your method implementation?

> 
> I guess that's what it comes down to, what *specific* use cases would this
> feature be intended to help with? Is there some code of your own that
> inspired you to propose it, or something you've seen publically that would
> benefit from it?

Originally, it was inspired by seeing Laravel's use of Arrayable as an 
interface and if something implements that, calling that class' `toArray()` 
method, and wishing that was built in so that frameworks didn't re-invent the 
wheel every time. 

As far as in my code, collections being cast as an array easily would be nice. 
Models with relationships, being able to implement that cast and control how 
your model and its children are (or aren't) represented. That's useful for 
returning an array in a controller for an API, or for simply adding context to 
a log message.

IMO, the point is, it's another tool in the developers arsenal that they can 
use when they see fit. Not everyone will use it and not everyone will see the 
benefit of it, and that's ok, but for those that would and could, __toArray() 
is for them (and me).

--
Steven Wade
stevenwad...@gmail.com




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Proposal for a RFC

[Steven Wade]

Hi Kalle,

> On May 4, 2019, at 12:08 PM, Kalle Sommer Nielsen  wrote:
> 
> Hi
> 
> Den lør. 4. maj 2019 kl. 17.58 skrev Steven Wade :
>> 
>> Hi Internals team!
>> 
>> I have an idea for a feature that I'd love to see in the language one day 
>> and wanted to run the idea by you all.
>> 
>> The idea is to add a new magic method "__toArray()" that would allow a 
>> developer to specifiy how a class is cast to an array. The idea is the same 
>> mentality of __toString(), but, for arrays.
> 
> While this sounds great and all, I do wonder about the implications it
> may have on the already existing behavior of type casting an object
> into an array which returns current public/protected/private property
> values. While this functionality is not an ideal or by design, it is
> fairly heavily (ab-)used, meaning that it is a potential BC break
> without the ability to an alternative.
> 
> See this example: https://3v4l.org/ONMoi 

That's a great example, thanks for that. I can understand how casting now can 
be as you say "abused". With my proposal, the default behavior wouldn't change 
unless someone implemented the __toArray() method on their class, which would 
simply give them greater control over how that class is represented.

In regards to the output of the example you linked, the same is possible today 
with reflection: https://3v4l.org/Ab51l 

If libraries are using casting to gain insight into objects, it seems that they 
could be updated to use reflection without losing any functionality.

--
Regards,

Steven Wade
stevenwad...@gmail.com

Re: [PHP-DEV] Proposal for a RFC

[Steven Wade]

Hi Marco,

> The alternative is to expand the reflection API with an array cast operation 
> in there, and then migrate existing userland usages to that to retain BC.

That's an interesting proposal - adding new reflection abilities. Hm..

> In addition to that, as someone that used to write a lot of `__toString()` 
> (and now doesn't do that anymore), a clear API and interfaced (non-magic) 
> `toArray()` is more powerful and useful.


I see you and I hear you. After 12 years, still like the magic of PHP. I like 
that casting is quick, simple, and is less verbose when writing/reading. But 
I'm not opposed to further discussing possible solutions. If this gets to the 
RFC stage, I'd prefer it be the best option for the language and most likely to 
pass.

--
Steven Wade
stevenwad...@gmail.com

Re: [PHP-DEV] Proposal for a RFC

[Marco Pivetta]

Hey Steven,


On Tue, 7 May 2019, 14:25 Steven Wade,  wrote:

> > I’m not against the proposal. I’m mainly asking if there are other ways
> in the language today to accomplish similar things. I would prefer to see
> interfaces used over more magic methods (something like ArraySerializable).
>
> A Twitter user pointed out that 7.4 is adding two new magic methods <
> https://wiki.php.net/rfc/custom_object_serialization> - __serialize() and
> __unserialize(). So adding more magic methods to PHP isn't unprecedented.
>
> On the same note, casting is already magical, so controling the
> implementation via a magic method is more in line with current
> functionality.
>

With your current proposal so far, I'd simply have to throw an exception:
`if (method_exists($object, '__toArray')) { throw
UnsupportedObject::from($object); }`

The alternative is to expand the reflection API with an array cast
operation in there, and then migrate existing userland usages to that to
retain BC.

In addition to that, as someone that used to write a lot of `__toString()`
(and now doesn't do that anymore), a clear API and interfaced (non-magic)
`toArray()` is more powerful and useful.

Greets,

Marco

Re: [PHP-DEV] Proposal for a RFC

[Steven Wade]

> On May 7, 2019, at 8:52 AM, Stephen Reay  wrote:
> 
> 
>> On 7 May 2019, at 19:47, Steven Wade  wrote:
>> 
>>> Maybe I’m missing the point (I’ve never used it) of VarDumper, but isn’t 
>>> this type of thing exactly why the `__debugInfo` magic method exists?
>> 
>> 
>> I can't speak for the exact reason a library like VarDumper is using casting 
>> versus __debugInfo, but in trying to find a substitute this morning, I 
>> played with the method you mentioned and found that it can be overwritten by 
>> classes and be commanded to not return anything (similar to my __toArray 
>> proposal), whereas current functionality prevents overriding casting to an 
>> array so casting will always give you insight but users can overwrite 
>> __debugInfo and cause unintended effects. I assume that's the reason for not 
>> using __debugInfo.
>> 
>> --
>> Steven Wade
>> stevenwad...@gmail.com
>> 
>> 
>> 
> 
> Right, I understand that it *can* be overridden, but surely if someone’s 
> doing that, its because they want more useful information provided in, e.g. 
> var_dump.


I think that's a good point. If we follow that mentality, then the proposed 
__toArray and it's subsequent ability to affect array casting isn't a worry too 
much as the proposal is to only call __toArray if it exists and an object is 
cast to an array, so if a user manually implements __toArray, then we could 
assume "they want more useful information provided in, e.g. var_dump."

--
Steven Wade
stevenwad...@gmail.com




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Proposal for a RFC

[Stephen Reay]

> On 7 May 2019, at 19:47, Steven Wade  wrote:
> 
>> Maybe I’m missing the point (I’ve never used it) of VarDumper, but isn’t 
>> this type of thing exactly why the `__debugInfo` magic method exists?
> 
> 
> I can't speak for the exact reason a library like VarDumper is using casting 
> versus __debugInfo, but in trying to find a substitute this morning, I played 
> with the method you mentioned and found that it can be overwritten by classes 
> and be commanded to not return anything (similar to my __toArray proposal), 
> whereas current functionality prevents overriding casting to an array so 
> casting will always give you insight but users can overwrite __debugInfo and 
> cause unintended effects. I assume that's the reason for not using 
> __debugInfo.
> 
> --
> Steven Wade
> stevenwad...@gmail.com
> 
> 
> 

Right, I understand that it *can* be overridden, but surely if someone’s doing 
that, its because they want more useful information provided in, e.g. var_dump.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Proposal for a RFC

[Steven Wade]

> Maybe I’m missing the point (I’ve never used it) of VarDumper, but isn’t this 
> type of thing exactly why the `__debugInfo` magic method exists?


I can't speak for the exact reason a library like VarDumper is using casting 
versus __debugInfo, but in trying to find a substitute this morning, I played 
with the method you mentioned and found that it can be overwritten by classes 
and be commanded to not return anything (similar to my __toArray proposal), 
whereas current functionality prevents overriding casting to an array so 
casting will always give you insight but users can overwrite __debugInfo and 
cause unintended effects. I assume that's the reason for not using __debugInfo.

--
Steven Wade
stevenwad...@gmail.com




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Proposal for a RFC

[Stephen Reay]

> On 7 May 2019, at 19:22, Nikita Popov  wrote:
> 
> On Tue, May 7, 2019 at 2:20 PM Steven Wade  wrote:
> 
>>> I want to weight in with what Marco expressed. I have the very same
>> concerns and they are major ones for many use cases. Mine is VarDumper.
>>> 
>>> Please don't do this the way it is described.
>> 
>> 
>> Is there a way that you'd suggest? First of all, TIL some cool things
>> about "(array) $foo" and how VarDumper uses that, so thank you! Secondly, I
>> believe the casting syntax is the best user experience and would be a good
>> addition to the language, so is there any other way at all to maintain
>> something like VarDumper's functionality without using the casting syntax?
>> I'd like to find a way to not distrupt too much of what's out there, while
>> also adding value to the end user.
>> 
> 
> We can add a separate function to provide this functionality. We should do
> that anyway because it's both clearer and because (array) already requires
> some special handling for ArrayObject that could be avoided.
> 
> Nikita
> 
> On Tue, May 7, 2019 at 2:20 PM Steven Wade  wrote:
> 
>>> I want to weight in with what Marco expressed. I have the very same
>> concerns and they are major ones for many use cases. Mine is VarDumper.
>>> 
>>> Please don't do this the way it is described.
>> 
>> 
>> Is there a way that you'd suggest? First of all, TIL some cool things
>> about "(array) $foo" and how VarDumper uses that, so thank you! Secondly, I
>> believe the casting syntax is the best user experience and would be a good
>> addition to the language, so is there any other way at all to maintain
>> something like VarDumper's functionality without using the casting syntax?
>> I'd like to find a way to not distrupt too much of what's out there, while
>> also adding value to the end user.
>> 
>> --
>> Steven Wade
>> stevenwad...@gmail.com
>> 
>> 
>> 
>> 
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>> 
>> 

Maybe I’m missing the point (I’ve never used it) of VarDumper, but isn’t this 
type of thing exactly why the `__debugInfo` magic method exists?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Proposal for a RFC

[Steven Wade]

> We can add a separate function to provide this functionality. We should do 
> that anyway because it's both clearer and because (array) already requires 
> some special handling for ArrayObject that could be avoided.


Are you talking about adding a separate function to replace my proposed 
__toArray() and casting functionality? Or did you mean adding a separate 
function to add functionality and insight into objects that packages like 
VarDumper have been using casting to access?

--
Steven Wade
stevenwad...@gmail.com




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Proposal for a RFC

[Steven Wade]

> I’m not against the proposal. I’m mainly asking if there are other ways in 
> the language today to accomplish similar things. I would prefer to see 
> interfaces used over more magic methods (something like ArraySerializable).

A Twitter user pointed out that 7.4 is adding two new magic methods 
 - __serialize() and 
__unserialize(). So adding more magic methods to PHP isn't unprecedented. 

On the same note, casting is already magical, so controling the implementation 
via a magic method is more in line with current functionality.

--
Steven Wade
stevenwad...@gmail.com

Re: [PHP-DEV] Proposal for a RFC

[Nikita Popov]

On Tue, May 7, 2019 at 2:20 PM Steven Wade  wrote:

> > I want to weight in with what Marco expressed. I have the very same
> concerns and they are major ones for many use cases. Mine is VarDumper.
> >
> > Please don't do this the way it is described.
>
>
> Is there a way that you'd suggest? First of all, TIL some cool things
> about "(array) $foo" and how VarDumper uses that, so thank you! Secondly, I
> believe the casting syntax is the best user experience and would be a good
> addition to the language, so is there any other way at all to maintain
> something like VarDumper's functionality without using the casting syntax?
> I'd like to find a way to not distrupt too much of what's out there, while
> also adding value to the end user.
>

We can add a separate function to provide this functionality. We should do
that anyway because it's both clearer and because (array) already requires
some special handling for ArrayObject that could be avoided.

Nikita

On Tue, May 7, 2019 at 2:20 PM Steven Wade  wrote:

> > I want to weight in with what Marco expressed. I have the very same
> concerns and they are major ones for many use cases. Mine is VarDumper.
> >
> > Please don't do this the way it is described.
>
>
> Is there a way that you'd suggest? First of all, TIL some cool things
> about "(array) $foo" and how VarDumper uses that, so thank you! Secondly, I
> believe the casting syntax is the best user experience and would be a good
> addition to the language, so is there any other way at all to maintain
> something like VarDumper's functionality without using the casting syntax?
> I'd like to find a way to not distrupt too much of what's out there, while
> also adding value to the end user.
>
> --
> Steven Wade
> stevenwad...@gmail.com
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Proposal for a RFC

[Steven Wade]

> I want to weight in with what Marco expressed. I have the very same concerns 
> and they are major ones for many use cases. Mine is VarDumper.
> 
> Please don't do this the way it is described.


Is there a way that you'd suggest? First of all, TIL some cool things about 
"(array) $foo" and how VarDumper uses that, so thank you! Secondly, I believe 
the casting syntax is the best user experience and would be a good addition to 
the language, so is there any other way at all to maintain something like 
VarDumper's functionality without using the casting syntax? I'd like to find a 
way to not distrupt too much of what's out there, while also adding value to 
the end user.

--
Steven Wade
stevenwad...@gmail.com




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Proposal for a RFC

[Ben Ramsey]

> On May 6, 2019, at 09:37, Steven Wade  wrote:
> 
> That being said, adding an interface like `ArraySerializable` might be nice 
> too. I'm seeing technical arguments against adding magic casts, but (just 
> spit-balling here), what if a class implemented a new `ArraySerializable` 
> interace with whatever method it demands, and if that is attempted to be cast 
> to an array either manually by calling "(array) $foo" or PHP attempting to, 
> then the array serialize method is called. ¯\_(ツ)_/¯

That’s how I would prefer to see it work.

BTW, I’m not suggesting `ArraySerializable` as the name. I used that to make a 
connection to `JsonSerializable`, which I think did a good job of using an 
interface for this kind of thing (even though it’s not quite the same because 
there’s no cast for a JSON type).

In some of my open source projects, I’ve had to add `__toString()` to the 
interfaces to ensure that implementers implement it. It would be nice for my 
interfaces to instead extend an internal interface like `Stringable`.

-Ben


signature.asc
Description: Message signed with OpenPGP

Re: [PHP-DEV] Proposal for a RFC

[Steven Wade]

> On May 5, 2019, at 10:59 AM, Ben Ramsey  wrote:
> 
> 
>> On May 4, 2019, at 09:58, Steven Wade  wrote:
>> 
>> Hi Internals team!
>> 
>> I have an idea for a feature that I'd love to see in the language one day 
>> and wanted to run the idea by you all. 
>> 
>> The idea is to add a new magic method "__toArray()" that would allow a 
>> developer to specifiy how a class is cast to an array. The idea is the same 
>> mentality of __toString(), but, for arrays.
>> 
>> I would personally love this feature and those I've run it by were also 
>> excited by the idea. So I'm soliciting feedback in hopes that things go well 
>> and I can officially write the RFC. As for implementation, Sara Golemon is 
>> awesome and while chatting a few months back, knocked out a proof-of-concept 
>> implementation 
>> .  There's 
>> still work to be done if this proposal gets to the RFC phase, but again, 
>> just gauging interest here.
>> 
>> I appreciate any feedback you all can provide.
>> 
>> Thanks,
>> 
>> - Steven Wade
> 
> Using existing language functionality, would it satisfy the similar needs if 
> you implement IteratorAggregate and return an ArrayIterator from the 
> getIterator() method? Obviously, the (array) cast wouldn’t use this, but you 
> could do $object->getIterator()->getArrayCopy().
> 
> I’m not against the proposal. I’m mainly asking if there are other ways in 
> the language today to accomplish similar things. I would prefer to see 
> interfaces used over more magic methods (something like ArraySerializable).

PHP already has the magic built in. The proposal is really just a way to 
control the magic. We already have "(string) $foo" and "__toString()", so the 
idea of implementing a "__toArray()" method is bringing a feature more inline 
with what's already there. 

I think it reads easier and cleaner "(array) $foo", and a simpler as a 
developer to implement than a mix of chained methods and interfaces.

That being said, adding an interface like `ArraySerializable` might be nice 
too. I'm seeing technical arguments against adding magic casts, but (just 
spit-balling here), what if a class implemented a new `ArraySerializable` 
interace with whatever method it demands, and if that is attempted to be cast 
to an array either manually by calling "(array) $foo" or PHP attempting to, 
then the array serialize method is called. ¯\_(ツ)_/¯



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Proposal for a RFC

[Nicolas Grekas]

Le sam. 4 mai 2019 à 18:37, Marco Pivetta  a écrit :

> Hi Steven,
>
> As it currently stands, the array cast is the only operation capable of
> exposing object state without triggering any kind of access guards: it is
> very much required for anything that works with reflection and typed
> properties, and possibly the only operation in PHP that operates on state
> without some contraption intercepting its execution.
>
> It is also necessary to distinguish dynamic properties from declared object
> state.
>
> For comparison, all of the following have side-effects due to the
> complexity of the language:
>
>  * isset()
>  * unset()
>  * property read
>  * property write
>  * ReflectionProperty#getValue()
>  * ReflectionProperty#setValue()
>
> Overall, this is problematic, and introduces more magic that I'd gladly
> avoid, in an endpoint used to work around all the engine magic (the only
> stable one so far).
>
> From my end, this sounds like a bad idea, because it removes one of the
> very very few referentially transparent guarantees (if not the only one,
> when dealing with objects) from the language.
>
> Greets,
>
> Marco
>

I want to weight in with what Marco expressed. I have the very same
concerns and they are major ones for many use cases. Mine is VarDumper.

Please don't do this the way it is described.

Nicolas

Re: [PHP-DEV] Proposal for a RFC

[Ben Ramsey]

> On May 4, 2019, at 09:58, Steven Wade  wrote:
> 
> Hi Internals team!
> 
> I have an idea for a feature that I'd love to see in the language one day and 
> wanted to run the idea by you all. 
> 
> The idea is to add a new magic method "__toArray()" that would allow a 
> developer to specifiy how a class is cast to an array. The idea is the same 
> mentality of __toString(), but, for arrays.
> 
> I would personally love this feature and those I've run it by were also 
> excited by the idea. So I'm soliciting feedback in hopes that things go well 
> and I can officially write the RFC. As for implementation, Sara Golemon is 
> awesome and while chatting a few months back, knocked out a proof-of-concept 
> implementation 
> .  There's 
> still work to be done if this proposal gets to the RFC phase, but again, just 
> gauging interest here.
> 
> I appreciate any feedback you all can provide.
> 
> Thanks,
> 
> - Steven Wade

Using existing language functionality, would it satisfy the similar needs if 
you implement IteratorAggregate and return an ArrayIterator from the 
getIterator() method? Obviously, the (array) cast wouldn’t use this, but you 
could do $object->getIterator()->getArrayCopy().

I’m not against the proposal. I’m mainly asking if there are other ways in the 
language today to accomplish similar things. I would prefer to see interfaces 
used over more magic methods (something like ArraySerializable).

-Ben

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Proposal for a RFC

[Marco Pivetta]

Hi Steven,

As it currently stands, the array cast is the only operation capable of
exposing object state without triggering any kind of access guards: it is
very much required for anything that works with reflection and typed
properties, and possibly the only operation in PHP that operates on state
without some contraption intercepting its execution.

It is also necessary to distinguish dynamic properties from declared object
state.

For comparison, all of the following have side-effects due to the
complexity of the language:

 * isset()
 * unset()
 * property read
 * property write
 * ReflectionProperty#getValue()
 * ReflectionProperty#setValue()

Overall, this is problematic, and introduces more magic that I'd gladly
avoid, in an endpoint used to work around all the engine magic (the only
stable one so far).

>From my end, this sounds like a bad idea, because it removes one of the
very very few referentially transparent guarantees (if not the only one,
when dealing with objects) from the language.

Greets,

Marco

On Sat, 4 May 2019, 16:58 Steven Wade,  wrote:

> Hi Internals team!
>
> I have an idea for a feature that I'd love to see in the language one day
> and wanted to run the idea by you all.
>
> The idea is to add a new magic method "__toArray()" that would allow a
> developer to specifiy how a class is cast to an array. The idea is the same
> mentality of __toString(), but, for arrays.
>
> I would personally love this feature and those I've run it by were also
> excited by the idea. So I'm soliciting feedback in hopes that things go
> well and I can officially write the RFC. As for implementation, Sara
> Golemon is awesome and while chatting a few months back, knocked out a
> proof-of-concept implementation <
> https://github.com/sgolemon/php-src/tree/experimental.toarray>.  There's
> still work to be done if this proposal gets to the RFC phase, but again,
> just gauging interest here.
>
> I appreciate any feedback you all can provide.
>
> Thanks,
>
> - Steven Wade

Re: [PHP-DEV] Proposal for a RFC

[Paul Jones]

> On May 4, 2019, at 11:08, Kalle Sommer Nielsen  wrote:
> 
> Hi
> 
> Den lør. 4. maj 2019 kl. 17.58 skrev Steven Wade :
>> 
>> Hi Internals team!
>> 
>> I have an idea for a feature that I'd love to see in the language one day 
>> and wanted to run the idea by you all.
>> 
>> The idea is to add a new magic method "__toArray()" that would allow a 
>> developer to specifiy how a class is cast to an array. The idea is the same 
>> mentality of __toString(), but, for arrays.
> 
> While this sounds great and all, I do wonder about the implications it
> may have on the already existing behavior of type casting an object
> into an array which returns current public/protected/private property
> values.

I find it easy to imagine that objects not implementing __toArray() would 
continue to exhibit that behavior.


-- 
Paul M. Jones
pmjo...@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Proposal for a RFC

[Kalle Sommer Nielsen]

Hi

Den lør. 4. maj 2019 kl. 17.58 skrev Steven Wade :
>
> Hi Internals team!
>
> I have an idea for a feature that I'd love to see in the language one day and 
> wanted to run the idea by you all.
>
> The idea is to add a new magic method "__toArray()" that would allow a 
> developer to specifiy how a class is cast to an array. The idea is the same 
> mentality of __toString(), but, for arrays.

While this sounds great and all, I do wonder about the implications it
may have on the already existing behavior of type casting an object
into an array which returns current public/protected/private property
values. While this functionality is not an ideal or by design, it is
fairly heavily (ab-)used, meaning that it is a potential BC break
without the ability to an alternative.

See this example: https://3v4l.org/ONMoi

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Proposal for a RFC

[Kalle Sommer Nielsen]

> I find it easy to imagine that objects not implementing __toArray() would 
> continue to exhibit that behavior.

Obviously. So what about code that operates on this behavior, should
that then suddenly break if the object implements an __toArray()
method? That sounds wrong to me


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Proposal for a RFC

[Paul Jones]

Hi Steven,

> The idea is to add a new magic method "__toArray()" that would allow a 
> developer to specifiy how a class is cast to an array. The idea is the same 
> mentality of __toString(), but, for arrays.

I'd like to see this as well.


-- 
Paul M. Jones
pmjo...@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Proposal for a RFC

[Steven Wade]

Hi Internals team!

I have an idea for a feature that I'd love to see in the language one day and 
wanted to run the idea by you all. 

The idea is to add a new magic method "__toArray()" that would allow a 
developer to specifiy how a class is cast to an array. The idea is the same 
mentality of __toString(), but, for arrays.

I would personally love this feature and those I've run it by were also excited 
by the idea. So I'm soliciting feedback in hopes that things go well and I can 
officially write the RFC. As for implementation, Sara Golemon is awesome and 
while chatting a few months back, knocked out a proof-of-concept implementation 
.  There's still 
work to be done if this proposal gets to the RFC phase, but again, just gauging 
interest here.

I appreciate any feedback you all can provide.

Thanks,

- Steven Wade