Re: Proposal: ArraySerializable interface
| From: | chobie | Date: | Wed, 11 Dec 2013 15:29:37 +0000 |
| Subject: | Re: Proposal: ArraySerializable interface | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-70592@lists.php.net to get a copy of this message | ||
2013/12/11 Marco Pivetta <ocramius@gmail.com>:
> I am personally (currently) relying on the approach where array conversion
> gives me the values of the various properties as objects (when they are
> objects), so I wouldn't like another magic operator in there (to deal
> with/workaround).
> Wondering why this approach would be better than doing a recursive array map
> iteration.
>
> Pardon my naive and inelegant way of dealing with maps (see the running
> example at http://3v4l.org/ZOodL ):
Yea, I also use same approach. let me explain my story:
I'm working at web gaming company and maintain many models which are
complex and nested classes.( like Player, Inventory, Item... )
Currently, We use
toArray or whatever method when passing those
variables to web browser.
Issue with this approach:
Developer have to consider returning values which handle recursively,
removing unwanted values...etc.
Also, Unfortunately this approach is company specific. We'd like to
follow common way to cast array from object.
The pros of proposed approach:
* Easy to convert to array from complex object.
returning value only contains primitive types (long, double, string,
array). and call __toArray method recursively when the value
contains object.
I think this rule will reduce production costs. just define
__toArray method and wanted returning values. don't care about other
things.
> I'm actually wondering about the opposite case.
> What would I have to do to have the previous behavior working on an
> ArraySerializable instance (basically ignore
> __toArray() for one particular cast)?
> I don't want to go the reflection way :-)
I'm curious about your story. What king of work do you do?
This kind of proposes regards coding standards. It's okay to propose which part.