Re: Traits and Conflicts: Collisions as Warnings or Fatal?

From: Date: Sun, 05 Dec 2010 14:53:13 +0000
Subject: Re: Traits and Conflicts: Collisions as Warnings or Fatal?
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-50849@lists.php.net to get a copy of this message
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 <php@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 >

« previous php.internals (#50849) next »