On Tue, Feb 28, 2012 at 6:05 AM, Anthony Ferrara <ircmax...@gmail.com>wrote:
> Ok, I've made a proof-of-concept patch here: > https://gist.github.com/1929587 > > Note that there are still a few memory leaks in there that would need > to be cleaned up, but I just wanted to make a really quick POC before > cleaning anything up to make it worthy of addition... > > One could use zend_get_type_by_const() for help :) Another patch would need to be made for the __castFrom($value) > implementation, but I think we'll split that off into another > topic/RFC since that's quite a bit more work than this is... > > What are your thoughts? > Anyway... I like but the changes would really need some documentation. And before that, we would need several RFC (one per concept seems to be a good idea). > > It adds 2 new magic methods: __castTo($type) and __assign($value): > > __castTo($type) is called by the cast_object handler, and the get > handler. The cast_object handler will pass in the requested type as a > string (NULL, boolean, integer, double, string, array, object, > resource, callable). Note that it does not check the return type (yet > at least). The get handler will pass in "native" as $type. So that's > used by combination operators (+=, +=, etc). > > __assign($value) is called by the set handler. This gets called > anytime the object is assigned to. To allow for conditional > assignment, if you return false from the handler, the value overwrites > the zval (to allow for destructing of the object and not overriding > assignment, if you want)... > > So, with this script: > > <?php > class Foo { > public $value = 1; > } > class Bar { > public $value = 1; > public function __castTo($type) { > return $this->value; > } > public function __assign($value) { > $this->value = $value; > return $value != 10; > } > } > > $a = new Foo; > $b = new Bar; > $a++; > var_dump($a); // int(1) - Normal type casting rules apply here. > $b++; > var_dump($b); // object, value = 2, increment captured > > $a = new Foo; > $b = new Bar; > $a = 3; > $b = 3; > var_dump($a); // int(3) - Normal rules apply > var_dump($b); // object, value = 3, assignment captured > > $a = new Foo; > $b = new Bar; > $a = 10; > $b = 10; > var_dump($a); // int(10) - Normal rules apply > var_dump($b); // int(10) - False was returned, so normal assignment happens > > > Now, for some casting: > $a = new Foo; > $b = new Bar; > $a->value = 100; > $b->value = 100; > var_dump((int) $a); // int(1) - Normal type casting rules apply > var_dump((int) $b); // int(100) - Cast was captured > > $a = new Foo; > $b = new Bar; > $a->value = 2; > $b->value = 2; > var_dump(substr("test", $a)); // string(1) "t" > var_dump(substr("test", $b)); // string(1) "te" > > Anthony > Sorry for repeating, but why not RFC that ? Julien.P > > On Mon, Feb 27, 2012 at 3:24 PM, Anthony Ferrara <ircmax...@gmail.com> > wrote: > > Rich, > > > > I appreciate the candid and honest nature of your reply, while > > maintaining civility. This list needs more of that. Further replies > > inline: > > > > On Mon, Feb 27, 2012 at 1:54 PM, Richard Lynch <c...@l-i-e.com> wrote: > >> On Mon, February 27, 2012 9:20 am, Anthony Ferrara wrote: > >>>> I have to say that no matter how much a luv my OOP, turning every > >>>> built-in type into an Object is just a Bad Idea... > >>>> > >>>> It's a form of bloat on RAM and CPU with minimal added value, imho. > >> > >>> Re-read what I had written. I never said to turn every built-in type > >>> into an object. In fact, what I was talking about was keeping and > >>> preserving the base types as-is. All that I was proposing was adding > >>> the ability to cast from and to the primitives. That way you could > >>> silently convert back and forth as needed (transparently when > >>> possible). > >>> > >> > >> I apologize that my brevity has been misconstrued. > >> > >> You are certainly free, even with the tools available in PHP, to > >> "wrap" an object around integers, strings, and so on. > >> > >> There may even be occasions where I think that would be a Good Idea > (tm). > > > > Well, you can kind of do it now. You can't directly operate on those > > objects. You need to first manually cast them back to the native > > type. Take a look at SplFixedArray ( > > http://www.php.net/manual/en/class.splfixedarray.php ). It has a pair > > of methods, a static fromArray(), and a instance toArray(). What I'm > > talking about is adding the ability to push these conversions down to > > the engine level. > > > >> What I object to is building such a facility into core PHP, because: > >> > >> 1) You can already do it in userland, and I believe that's where it > >> belongs. > > > > Actually, almost exactly the opposite. You can't do it in userland, > > but you can in a PECL extension (via cast_object(), get() and set()). > > The first part of this proposal is basically just exposing those > > methods (almost 1:1, only consolidating cast_object and get into a > > single method with a parameter defining the difference). > > > >> 2) It unnecessarily [see 1] complicates core PHP, whose major > >> strengths that drive its success includes its simplicity. > > > > Actually, the first part of the proposal doesn't really change the > > core that much. All it does is add standard object handlers to expose > > cast_object (which is already partially exposed via __toString), get > > and set (which are currently null). There shouldn't really be other > > changes required to the core for the first part at least. > > > > The second part of the proposal (the castFrom auto-casting) would > > require some more changes to the core, and be much more significant. > > To be honest, I think that would be a separate effort (and a separate > > RFC) the more I think about it. > > > >>>> No matter which way you twist this pretzel: > >> > >> I had hoped that this bit would hint that all the proposals along > >> these lines, including yours, are proposals I would vote against, even > >> though I did over-blow your actual proposal. > >> > >>>> -1 > >> > >>> So what it sounds like you're -1ing to, is not actually what was > >>> proposed... > >>> > >>> I'm starting to work on a patch for this as a proof of concept... > >> > >> Please do so! > >> > >> I'll still vote -1, but obviously others will vote as they see fit. > >> > >> All these ideas are welcome. The ones with complete patches even more > >> so, as they allow a true idea of what the change would mean. > >> > >> Unfortunately, however, I must repeat that, so far, the idea has > >> always fallen flat on its face when the proposer actually attempts to > >> put action into deed, making a patch that fully meets their proposal. > >> > >> That doesn't mean you can't succeed, if you are more skilled than all > >> your predecessors. > > > > I don't think skill has that much to do with it. I think the real key > > difference is what's being attempted... > > > > Anthony > > > >> -- > >> brain cancer update: > >> http://richardlynch.blogspot.com/search/label/brain%20tumor > >> Donate: > >> > https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE > >> > >> > >> > >> -- > >> PHP Internals - PHP Runtime Development Mailing List > >> To unsubscribe, visit: http://www.php.net/unsub.php > >> > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
