Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35716
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lorenso.com from 67.18.161.90 cause and error)
Message-ID: <47BE3692.8030602@lorenso.com>
Date: Thu, 21 Feb 2008 20:42:26 -0600
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: php@stefan-marr.de
CC: Internals Mailing List <internals@lists.php.net>
References: <001c01c87264$3c01b4e0$b4051ea0$@de> <698DE66518E7CA45812BD18E807866CE014A8D9D@us-ex1.zend.net> <47BE0664.8060304@stefan-marr.de> <47BE0A09.6060702@lorenso.com> <47BE0CC4.1090202@stefan-marr.de>
In-Reply-To: <47BE0CC4.1090202@stefan-marr.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: Traits for PHP ... Why can't every Class be a Trait?
From: dante@lorenso.com ("D. Dante Lorenso")

Stefan Marr wrote:
> Hi,
> 
> D. Dante Lorenso schrieb:
>> All,
>>
>> I can imagine a case where you would want to box common functionality 
>> into a trait and be able to use that trait as a class also.  Will we 
>> end up with a lot of classes like this?:
>>
>> class SomeClass {
>>   use SomeTrait;
>> }
>>
>> What's wrong with making all 'Class'es be 'Trait's and the only thing 
>> which makes a Trait a Trait is when you use it as such?
>>
>> class MyClass {
>>   trait SomeClass;
>> }
>>
>> In other words, why mustn't a trait be instantiable?  Why can't every 
>> Class be a Trait?
> 
> Well, the trait concept is not a silver bullet for all problems out there.
> What is wrong with inheritance or delegation for reusing complex 
> behavior? Traits are for finer grained reuse in my eyes.
> The usage I've seen so far suggests typical traits are about 1 to 5 
> methods, but the average method count on a trait would be 1.88 or 
> something like this (just a rule of thumb. from what I personally have 
> looked at).

I agree Traits are cool for what they do.  I'm saying that we don't need 
to introduce a new "thing" called a Trait just to do what traits are doing.

The magical part of Traits is the flattening of included class 
components.  Just do this flattening with things defined as a Class and 
we won't have to introduce yet another kind of thing.

Not all classes are meant to work as traits but the ones created with 
being a trait in mind would.  If you create a Class/Trait with 5 
methods, fine.  But you could just as easily create one with 50 methods.

Current Class + New Trait features = new Class

All you need to implement is the flattening declaration code:

----------
class MyClassWhichCouldBeATrait {
	...
}
class MyClass {
    suck MyClassWhichCouldBeATrait;
}
----------

BTW, can we add 'suck' to the list of alternate keywords ;-)

-- Dante