# Traits and Conflicts: Collisions as Warnings or Fatal? - Thread: https://externals.io/message/50848 - Original archive: https://news-web.php.net/php.internals/50848 - Started by Stefan Marr on 2010-12-05T14:03:55+00:00 - Messages: 4 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #50848 — Stefan Marr — 2010-12-05T14:03:55+00:00 URL: https://externals.io/message/50848#50848 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 --- ## #50849 — Benjamin Eberlei — 2010-12-05T14:53:13+00:00 URL: https://externals.io/message/50848#50849 · In reply to: #50848 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 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 --- ## #50891 — Stefan Marr — 2010-12-07T11:58:43+00:00 URL: https://externals.io/message/50848#50891 · In reply to: #50849 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 --- ## #50893 — Derick Rethans — 2010-12-07T12:03:43+00:00 URL: https://externals.io/message/50848#50893 · In reply to: #50848 > 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? 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