Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:35572 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 53771 invoked by uid 1010); 19 Feb 2008 01:36:33 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 53756 invoked from network); 19 Feb 2008 01:36:32 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 19 Feb 2008 01:36:32 -0000 Authentication-Results: pb1.pair.com smtp.mail=larry@garfieldtech.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=larry@garfieldtech.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 76.96.62.64 cause and error) X-PHP-List-Original-Sender: larry@garfieldtech.com X-Host-Fingerprint: 76.96.62.64 qmta07.westchester.pa.mail.comcast.net Received: from [76.96.62.64] ([76.96.62.64:45133] helo=QMTA07.westchester.pa.mail.comcast.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 02/DA-23568-0A23AB74 for ; Mon, 18 Feb 2008 20:36:32 -0500 Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA07.westchester.pa.mail.comcast.net with comcast id rDC31Y0011HzFnQ5703T00; Tue, 19 Feb 2008 01:36:11 +0000 Received: from earth.ufp ([24.13.255.226]) by OMTA14.westchester.pa.mail.comcast.net with comcast id rDcV1Y00C4trKQ83a00000; Tue, 19 Feb 2008 01:36:30 +0000 X-Authority-Analysis: v=1.0 c=1 a=NemShDG-jDtVUjZP5n4A:9 a=3AURfHP3_Sd9ms1PNFcA:7 a=SPWzwPTVAcDb3trtxXBbjfAPyv4A:4 a=FHBbIDN7CdwA:10 a=LY0hPdMaydYA:10 Received: from localhost (localhost [127.0.0.1]) by earth.ufp (Postfix) with ESMTP id 84D28D83FB for ; Mon, 18 Feb 2008 19:36:29 -0600 (CST) Received: from earth.ufp ([127.0.0.1]) by localhost (earth.hsd1.il.comcast.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YJVl8FYBErt for ; Mon, 18 Feb 2008 19:36:29 -0600 (CST) Received: from vulcan (unknown [192.168.42.1]) by earth.ufp (Postfix) with ESMTP id 67C58D83FA for ; Mon, 18 Feb 2008 19:36:19 -0600 (CST) To: internals@lists.php.net Date: Mon, 18 Feb 2008 19:36:17 -0600 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <001c01c87264$3c01b4e0$b4051ea0$@de> <58510.98.193.37.55.1203374232.squirrel@www.l-i-e.com> In-Reply-To: <58510.98.193.37.55.1203374232.squirrel@www.l-i-e.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <200802181936.17739.larry@garfieldtech.com> Subject: Re: [PHP-DEV] RFC: Traits for PHP From: larry@garfieldtech.com (Larry Garfield) On Monday 18 February 2008, Richard Lynch wrote: > On Mon, February 18, 2008 1:27 pm, php@stefan-marr.de wrote: > > > trait ezcReflectionReturnInfo { > > function getReturnType() { /*1*/ } > > function getReturnDescription() { /*2*/ } > > } > > > > class ezcReflectionMethod extends ReflectionMethod { > > use ezcReflectionReturnInfo; > > So it's just like an include for a re-used body of 'class' code. > > Hmmmm. > > Why not just allow 'include' here instead? > > :-) Because include requires the code in question to live in another file, which I don't always want. It sounds interesting to me, and I can definitely see the value. I think I'd suggest having multiple included traits override each other, however, so that: trait A { function foo() { echo "A"; } } trait B { function foo() { echo "B"; } } class C { use A; use B; } $c = new C(); $c->foo(); // prints "B" since that came second. That said, the conventional OOP mechanism to get the same result would, I think, look something like this: interface iface { function foo(); function bar(); } class I implements iface { function foo() { ... } function bar() { ... } } class A implements iface { protected $iface; function __construct() { $this->iface = new I(); } function foo() { return $this->iface->foo(); } function bar() { return $this->iface->bar(); } } The class/interface method takes a little more typing and an extra function call on the stack, but otherwise what is the advantage of Traits over this method? (Really, I'm genuinely curious.) You also note that this mechanism has no runtime impact. That's unfortunate, because I'd find the ability to add methods to an object at runtime conditionally based on some other value far more useful in my work. :-) Especially since, as above, there seems to be a way to implement this functionality now as-is with a little more typing, yet runtime modification is still impossible without eval() and similar scary stuff. Vis, I'd find the following more useful in the code I write: trait Baby { function crawl() { ... } } trait Teen { function complain() { ... } } class Person { protected $age; function __construct($age) { $this->age = $age; if ($this->age <= 3) { $this->addTrait('Baby'); } if ($this->age >=13 && $this->age <=19) { $this->addTrait(Teen'); } } } $p[1] = new Person(19); $p[1]->complain(); $p[2] = new Person(1); $p[2]->crawl(); foreach ($p as $person) { if ($p instanceof Teen) { $person->complain(); $person->parent->ground($person); } } I don't know if that's technically not feasible or technically not a Trait anymore and therefore off topic in this thread (if it is, that's fine, let me know and I'll shut up about it ), but that strikes me as more useful than just runtime composition. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson