Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35571
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.184.237 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=p1kyAe2kYuFbGb8uZoAjJbsGT63bkPU0ydUeFejBsgKH2yWzMfYRBE8APClp9AuJOFEJpedlbuLcb2vYHQARzHYcrpTk+eBYLVVw5/A1JmXknvP865GhQabi5WV4LzHMb45DpXtuU8Loe4nyGOXWFG0oTlKmDO5pI+wVlJMR5Ug=
Message-ID: <1e12984d0802181536t7fceafsef1975341ec29aff@mail.gmail.com>
Date: Tue, 19 Feb 2008 00:36:32 +0100
Sender: stefan.marr.de@gmail.com
To: ceo@l-i-e.com
Cc: internals@lists.php.net
In-Reply-To: <58510.98.193.37.55.1203374232.squirrel@www.l-i-e.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>
	 <58510.98.193.37.55.1203374232.squirrel@www.l-i-e.com>
Subject: Re: [PHP-DEV] RFC: Traits for PHP
From: php@stefan-marr.de ("Stefan Marr")

> So it's just like an include for a re-used body of 'class' code.
>
> Hmmmm.
>
> Why not just allow 'include' here instead?
Well, think this would be a Mixin mechanism like in Ruby.

> Forgive me if I'm missing something subtle/complex here, but I wonder
> if a Trait is really the "right answer"...
>
> Yes, the ability to add/exclude specific functions from two Traits is
> "gone" with a simple 'include'... But so is the complexity of yet
> another language construct...
The problem here is that we will need a way to handle conflicts i.e.
methods defined in more than one of the includes.
The mixin way is to apply one include at a time. So conflicts are
solved by overriding already defined methods. But this solution is not
perfect at all since there exist situations where you can not find an
order for the includes which provides you with the needed method
implementations. Additionally you will not notice when a method in an
included hierarchy will break your semantics by overriding other
methods unexpectedly.

The Traits way is to enable the developers to decide on such conflicts
and give them the power to re-use the methods exactly needed in this
special situation, instead of doing some "magic"/linearization to
solve conflicts.

Kind Regards
Stefan