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