> One could use zend_get_type_by_const() for help :) I wasn't aware of that function, thanks! I based it off of gettype ( http://lxr.php.net/opengrok/xref/PHP_5_4/ext/standard/type.c#26 ). I'll update the patch tonight.
> And before that, we would need several RFC (one per concept seems to be a > good idea). Well, considering they are tied together (at least __assign is useless without the __castTo), wouldn't the two of them fall into the same RFC? And I'm planning on writing out an RFC for it. I just wanted to get some comments and flush out the concept before writing an official patch and RFC. That's why I made a POC patch, to investigate the ramifications and prove it could be done before finalizing and proposing exactly how it should work... Thanks, Anthony On Tue, Feb 28, 2012 at 5:54 AM, jpauli <jpa...@php.net> wrote: > 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 >> > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
