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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
