Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58233 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 72135 invoked from network); 28 Feb 2012 12:34:00 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 28 Feb 2012 12:34:00 -0000 Authentication-Results: pb1.pair.com header.from=ircmaxell@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=ircmaxell@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender) X-PHP-List-Original-Sender: ircmaxell@gmail.com X-Host-Fingerprint: 209.85.216.170 mail-qy0-f170.google.com Received: from [209.85.216.170] ([209.85.216.170:38819] helo=mail-qy0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 0B/D3-47028-5B9CC4F4 for ; Tue, 28 Feb 2012 07:33:58 -0500 Received: by qcmt36 with SMTP id t36so1199705qcm.29 for ; Tue, 28 Feb 2012 04:33:54 -0800 (PST) Received-SPF: pass (google.com: domain of ircmaxell@gmail.com designates 10.229.78.98 as permitted sender) client-ip=10.229.78.98; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ircmaxell@gmail.com designates 10.229.78.98 as permitted sender) smtp.mail=ircmaxell@gmail.com; dkim=pass header.i=ircmaxell@gmail.com Received: from mr.google.com ([10.229.78.98]) by 10.229.78.98 with SMTP id j34mr7639607qck.36.1330432434665 (num_hops = 1); Tue, 28 Feb 2012 04:33:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Q4SnAyIHFEesq5CLMJLG5BSaJGATeeM/36ig778w/DU=; b=TOcGQ49gf8l8d+mSQshI9BRAvx1Wxw9tLmMOP1g+Wyy+3fSV8zMtUdMvMJ7Qpibdpv 3c0OuUw8wvDlsmVOcCNvWyGdTBo3+Ekq8jLnsQHnC4IIWxE7t9qf5wd4VFdd+tC24uUb Wi4yek4Nzk64d3QeqPdRRu4xyCSrPo8UWVxkU= MIME-Version: 1.0 Received: by 10.229.78.98 with SMTP id j34mr6297291qck.36.1330432434517; Tue, 28 Feb 2012 04:33:54 -0800 (PST) Received: by 10.229.166.202 with HTTP; Tue, 28 Feb 2012 04:33:54 -0800 (PST) In-Reply-To: References: <6d4a9f99bc550c8c673b32cbccc52444.squirrel@www.l-i-e.com> Date: Tue, 28 Feb 2012 07:33:54 -0500 Message-ID: To: jpauli Cc: Richard Lynch , internals@lists.php.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Object Casting - An Alternative to Type Hinting From: ircmaxell@gmail.com (Anthony Ferrara) > 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 wrote: > On Tue, Feb 28, 2012 at 6:05 AM, Anthony Ferrara > 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. =A0The cast_object handler will pass in the requested type as a >> string (NULL, boolean, integer, double, string, array, object, >> resource, callable). =A0Note that it does not check the return type (yet >> at least). =A0The get handler will pass in "native" as $type. =A0So that= 's >> used by combination operators (+=3D, +=3D, etc). >> >> __assign($value) is called by the set handler. =A0This gets called >> anytime the object is assigned to. =A0To 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: >> >> > class Foo { >> =A0 =A0public $value =3D 1; >> } >> class Bar { >> =A0 =A0public $value =3D 1; >> =A0 =A0public function __castTo($type) { >> =A0 =A0 =A0 =A0return $this->value; >> =A0 =A0} >> =A0 =A0public function __assign($value) { >> =A0 =A0 =A0 =A0$this->value =3D $value; >> =A0 =A0 =A0 =A0return $value !=3D 10; >> =A0 =A0} >> } >> >> $a =3D new Foo; >> $b =3D new Bar; >> $a++; >> var_dump($a); // int(1) - Normal type casting rules apply here. >> $b++; >> var_dump($b); // object, value =3D 2, increment captured >> >> $a =3D new Foo; >> $b =3D new Bar; >> $a =3D 3; >> $b =3D 3; >> var_dump($a); // int(3) - Normal rules apply >> var_dump($b); // object, value =3D 3, assignment captured >> >> $a =3D new Foo; >> $b =3D new Bar; >> $a =3D 10; >> $b =3D 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 =3D new Foo; >> $b =3D new Bar; >> $a->value =3D 100; >> $b->value =3D 100; >> var_dump((int) $a); // int(1) - Normal type casting rules apply >> var_dump((int) $b); // int(100) - Cast was captured >> >> $a =3D new Foo; >> $b =3D new Bar; >> $a->value =3D 2; >> $b->value =3D 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 >> wrote: >> > Rich, >> > >> > I appreciate the candid and honest nature of your reply, while >> > maintaining civility. =A0This list needs more of that. Further replies >> > inline: >> > >> > On Mon, Feb 27, 2012 at 1:54 PM, Richard Lynch 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. =A0I never said to turn every built-in t= ype >> >>> into an object. =A0In fact, what I was talking about was keeping and >> >>> preserving the base types as-is. =A0All that I was proposing was add= ing >> >>> the ability to cast from and to the primitives. =A0That way you coul= d >> >>> 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. =A0You can't directly operate on thos= e >> > objects. =A0You need to first manually cast them back to the native >> > type. =A0Take a look at SplFixedArray ( >> > http://www.php.net/manual/en/class.splfixedarray.php ). =A0It has a pa= ir >> > of methods, a static fromArray(), and a instance toArray(). =A0What 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. =A0You 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. =A0All it does is add standard object handlers to expo= se >> > cast_object (which is already partially exposed via __toString), get >> > and set (which are currently null). =A0There 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, eve= n >> >> 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. =A0The ones with complete patches even m= ore >> >> 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. =A0I think the real k= ey >> > 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=3D_s-xclick&hosted_button_i= d=3DFS9NLTNEEKWBE >> >> >> >> >> >> >> >> -- >> >> 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 >> >