Hi Christopher, thanks for (re-)starting the discussion how to make horizontal reuse easier in PHP.
Am Donnerstag, den 13.11.2008, 16:59 +0100 schrieb Christopher Vogt:
[...]
> I had a chat with Stefan about his Traits/Grafts RFC and he suggested we
> should rather continue a discussion here.
> I really liked to see the Grafts proposal. In traits and regular
> inheritance the implementation code of several entities is somehow mixed
> and as a result one entities code can break another entities code.
To keep things fair, there were proposals to keep traits completely
stateless and to allow abstract methods in traits, so that traits can
sort of "request" the implementation of a certain method. This would
keep the inheritance chain pretty stable.
> The
> great thing about Grafts is that the implementation is not mixed. Grafts
> are completely encapsulated entities with their own state. I think in
> many cases where inheritance or traits seem tempting, complete
> encapsulation is actually the cleaner solution.
I see the point of having encapsulated state, I still wonder if it would be
better for us to have something simpler. Simpler, as in avoiding state at all.
So if we had traits without state at all a) the concept is easy to explain
(like "interfaces define the API, classes keep state, traits encapsulate
implementation"). A nice and easy explainable hierarchy of responsibilities.
[... Details about grafts ...]
> However a problem remains. The methods of counter return $this (aka
> implement a fluent interface). One idea that came to my mind to solve
> this problem: PHP could provide a keyword fluent that replaces a methods
> return value to form a fluent interface i.e. return $this:
>
> class QueueTicketPrinter{
> use Counter as private $counter{
> public fluent current();
> public fluent reset();
> }
> public function takeNumber(){
> print 'your number is ".$this->counter->current();
> $this->counter->inc();
> }
> }
>
> The keyword fluent ignores whatever value the Counter function may
> return and returns an the instance of QueueTicketPrinter instead.
That's a good example why I have the feeling they are a hack. I mean a
"fluent" keyword just for a single use case. Another thing, how could I
return the class name of the current class? "public class current()".
And so on. At the end it is an issue of "late graft binding" (similar to
late static binding).
> Finally, can somebody provide a sensible use case for traits, that
> cannot be solved with Grafts? I am sure there is, but I am currently
> lacking one.
I can't think of any (except from late graft binding), however not
having anything against does not mean it is a good idea :) I still
prefer traits as they are easier to explain from my point of view, the
concept is more clear and that's the spirit that fits pretty well for
PHP.
cu, Lars
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
