Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41899
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <03.06.07308.9484C194@pb1.pair.com>
To: internals@lists.php.net
Date: Thu, 13 Nov 2008 16:31:20 +0100
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Thunderbird/1.5.0.7 Mnenhy/0.7.4.666
MIME-Version: 1.0
References: <002b01c92d67$ae92fdc0$0bb8f940$@de>
In-Reply-To: <002b01c92d67$ae92fdc0$0bb8f940$@de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Traits,Grafts, horizontal reuse
From: christopher.vogt@rwth-aachen.de (Christopher Vogt)

Hej everybody,

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. The
great thing about Grafts is that the implementation is not mixed. Grafts
are completely independent entities with their own state. I think in
many cases where inheritance or traits seem tempting, complete
encapsulation is actually the cleaner solution.

The Grafts proposal, however, suffered a little from being born out of
traits, I think. Something similar to Grafts is already possible in
current php, but it is not very beautiful. If we start from there
however, Grafts could become very helpful syntactic sugar. Let's look at
current PHP first:

class Counter {
  private $cnt = 0;
  public function inc() {
    $this->cnt++;
  }
  public function reset() {
    $this->cnt = -1;
    $this->inc();
  }
}
class TakeANumberForTheQueue{



, so this is one , but I think it could be even better when it was much
closer to current PHP than suggested in the RFC. Let me explain what I
mean. Graft were born out of the idea of traits. Traits are a variant of
inheritance and a trade-off between single and multiple inheritance with
the goal to reduce code duplication. The problem with inheritance is
that code can break because code from different classes (or traits) is
mixed together

 interfering with  Either kind of inheritance can be very tempting to be
used to reuse functionality.

implement code reuse. Code reuse is tempting but often enough it is not
really necessary to reuse the

comes from the wrong direction and didn't go far enough.

Traits conquer the lacks of single inheritance without giving the full
power of multiple inheritance. Traits are still sort of inheritance.
When a class uses a trait the trait's code can access class
implementation details and vice-vera. This might come in handy at some
point, however I personally lack a good use case for now. Can somebody
provide a sensible use case for traits?

A Problem with code inheritance (single, traits, whatever) is that the
possibility to use inheritance seduces to use it even when it is not
necessarily needed. Stefan's "Counter" example is a good one.

What I find even more promising than Traits are Grafts.

 I know Grafts where born out of the traits idea, but I want to try to
put them idea a little forward and separate the from the traits idea
even stronger than Stefan already did.

Why do we want Grafts?
Because inheritance can be a problem