Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35591
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.200.173 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=SJLCcx+EvOtTIhRDdxkJyHnzd1kjjAnGaRGnBXwyXbaiV6gk0UQ89spAt60yyCXMcADDCywuA07pFSDw5zj3RMY0c+VLKzew98fDTpE/5zxkEDGfubGbGRMjU+cPfEFieNANAy2WANzOEm61uw5GV24wZ8i9XE7P10Kwpo510A8=
Message-ID: <1e12984d0802190423r6410233ak1d15cfda3941d56f@mail.gmail.com>
Date: Tue, 19 Feb 2008 13:23:57 +0100
Sender: stefan.marr.de@gmail.com
To: RQuadling@googlemail.com
Cc: internals@lists.php.net
In-Reply-To: <10845a340802190234m4efbab0fqcf4e36ad3d812853@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <001c01c87264$3c01b4e0$b4051ea0$@de>
	 <10845a340802190234m4efbab0fqcf4e36ad3d812853@mail.gmail.com>
Subject: Re: [PHP-DEV] RFC: Traits for PHP
From: php@stefan-marr.de ("Stefan Marr")

Hi Richard,

> A question (and again, no idea on feasibility, internals, etc.).
>
> The above proposal covers adding/overriding internal methods with
> external ones. Is it possible to also include additional properties?
>
> If not, then you would have to override the constructor method (this
> could be demoted to documentation rather than code then I suppose).
the current proposal does not allow state in your traits.

At the moment the solution would be like this:

trait A {
   abstract protected function getFoo();
   public function doSomeFoo($bar) {
     return $this->getFoo().' baz ' . $bar;
   }
}

Traits can defined abstract methods to define a required method. This
abstract methods can be implemented in the class or in an other trait.

There are also notions about stateful traits out there. For instance
Scala does implement them, but state is an additional level of
complexity and I have tried to avoid it in this implementation, since
I have had expected much more complains about the aliasing and exclude
operations and its pretended complexity.
In my opinion stateful traits are the next logical step, but with the
cost for some additional complexity, since you need handle conflicting
properties. (The stateful traits approach is to make it private to a
traits composition, but this might not be obvious to every user.)

Kind Regards
Stefan