Re: Proposal: ArraySerializable interface

From: 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.

« previous php.internals (#70592) next »