Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35594
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender)
Date: Tue, 19 Feb 2008 15:32:22 +0100
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <75883486.20080219153222@marcus-boerger.de>
To: "Stefan Marr" <php@stefan-marr.de>
CC: ceo@l-i-e.com, internals@lists.php.net
In-Reply-To: <1e12984d0802181536t7fceafsef1975341ec29aff@mail.gmail.com>
References: <001c01c87264$3c01b4e0$b4051ea0$@de> <58510.98.193.37.55.1203374232.squirrel@www.l-i-e.com> <1e12984d0802181536t7fceafsef1975341ec29aff@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: Traits for PHP
From: helly@php.net (Marcus Boerger)

Hello Stefan,

  any dynamic aspect of a class has brought us to problems in inheritance
and required us to design the objct/compile model in a way that
inheritance often is done at run time. Imo traits are a way out of this.
In fact I'd love to issue a deprecated message as soon as class is found
outside of a main block.

marcus

Tuesday, February 19, 2008, 12:36:32 AM, you wrote:

>> 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




Best regards,
 Marcus