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
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=markupCollisions 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
Hi:
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.
So, that is the way to go?
The original idea to go with a warning was, that it is not the case that the engine is in an unrecoverable state, thus, the code actually will work in that case, but perhaps produce unexpected results.
In general, PHP uses fatals far to often for my taste, but well, to keep it consistent, we can go fatal here, too.
Is there a general consensus on that?
Thanks
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
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=markupCollisions 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?
IMO they should be fatal because your code is "broken".
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug