Re: RFC: Traits for PHP
| From: | Marcus Boerger | Date: | Tue, 19 Feb 2008 14:32:22 +0000 |
| Subject: | Re: RFC: Traits for PHP | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-35594@lists.php.net to get a copy of this message | ||
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