I wondered before why this only triggers a warning. A fatal error sounds good 
at that point in my opinion.

It is comparable to interfaces/Abstract classes being implemented wrong and 
this also leads to a fatal error. Additionally there is no way this "just" 
happens to your code. You have to make changes to a trait explicitly to trigger 
this problem, so this is only happening in development.

greetings,
Benjamin

On Sun, 5 Dec 2010 15:03:55 +0100
Stefan Marr <p...@stefan-marr.de> wrote:

> Hi:
> 
> While preparing some explanations on how to use traits, I stumbled over an 
> inconsistency in the current implementation.
> 
> Currently collisions, if they are explicit in the code, lead to a warning and 
> are resolved by explicit exclusion of the two methods that collide[1].
> However, there are other ways to provoke a collision, for instance by 
> introducing a new alias during composition[2].
> 
> [1] 
> http://svn.php.net/viewvc/php/php-src/trunk/Zend/tests/traits/error_015.phpt?revision=305512&view=markup
> [2] 
> http://svn.php.net/viewvc/php/php-src/trunk/Zend/tests/traits/language010.phpt?revision=305512&view=markup
> 
> 
> Collisions usually point to implementations that changed unexpectedly, and 
> the implicit resolution might be problematic since it could hide the real 
> cause for a bug.
> 
> So, should that warning be changed to a fatal error, or should the other 
> fatals be warnings, too?
> 
> Best regards
> Stefan
> 
> -- 
> Stefan Marr
> Software Languages Lab
> Vrije Universiteit Brussel
> Pleinlaan 2 / B-1050 Brussels / Belgium
> http://soft.vub.ac.be/~smarr
> Phone: +32 2 629 2974
> Fax:   +32 2 629 3525
> 
> 
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to