Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35712
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain stefan-marr.de from 82.96.83.42 cause and error)
Message-ID: <47BE092F.50504@stefan-marr.de>
Date: Fri, 22 Feb 2008 00:28:47 +0100
Reply-To: php@stefan-marr.de
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: jvlad <dmda@yandex.ru>
Cc: internals@lists.php.net
References: <47BD207C.2080905@chiaraquartet.net> <B6.F6.64513.16CFDB74@pb1.pair.com> <47BE014F.5020202@stefan-marr.de> <4E.B9.64513.1650EB74@pb1.pair.com>
In-Reply-To: <4E.B9.64513.1650EB74@pb1.pair.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: Trait aliasing syntax suggestions
From: php@stefan-marr.de (Stefan Marr)

Hi,

jvlad schrieb:
> Why would this create any problems? Say, you have class B that extends class 
> A and both do define one method and one property under the same names. Will 
> this create a problem? No. It's because there are rules that clearly 
> describe how it works (method and property will be overriden). Similar 
> approach may be applied to trait'ing classes. Why not? For example if you 
> have a property defined above trait'ing, it will be overriden by the trait 
> if it comes up with its own property with the same name (same goes for the 
> properties defined in the ancestor class). If trait defines a property, it 
> can be overriden by class if it introduce it below trait'ing statement.
> On the other hand, if someone being a developer cares of potential 
> "conflict" (unwanted override), he/she may simply not define properties and 
> constants in the class that's intended to be trait'ed into another class.
This contradicts the idea behind traits.
Here all conflicts are handled explicitly. Overriding is not used 
between traits to provide greater power and allow the notion of 
flattening in the way it has been proposed.
Your proposal is much like mixins. But mixins have limited composition 
power caused by this overriding. There are situations without a suitable 
linearization to get overlapping methods from to different mixins in the 
needed combination.

The complete argumentation can be found here: 
http://www.iam.unibe.ch/~scg/Archive/Papers/Duca06bTOPLASTraits.pdf
illustrating the cons of mixins and multiple inheritance.

Kind Regards
Stefan