Edit report at https://bugs.php.net/bug.php?id=61943&edit=1
ID: 61943 Comment by: franssen dot roland at gmail dot com Reported by: franssen dot roland at gmail dot com Summary: Trait same property conflict in class extending Status: Assigned Type: Feature/Change Request Package: Scripting Engine problem Operating System: Ubuntu PHP Version: 5.4.2 Assigned To: gron Block user comment: N Private report: N New Comment: Also i did'nt read your comment well, especially the "semantical difference" part.. ;-) Previous Comments: ------------------------------------------------------------------------ [2012-05-05 11:46:06] franssen dot roland at gmail dot com I cheered to soon :-) now Bar has 2 individual property definitions (makes sense ofcourse), so this doesn't solve my architecture problem. We can debat on if the architecture is a code smell or not, but i can understand i'm overusing traits here. Traits are simply not suitable for this. I'll revise it so that the traits complement each other, rather than "extending" each other. ------------------------------------------------------------------------ [2012-05-05 09:35:59] franssen dot roland at gmail dot com Of course.. private visibility.. you sir, are a genius :') I get away with this since the trait is mainly for accessors only. However, i have this (personal) convention to use protected properties with accessors, mainly pragmatic reasons (overriding default values by defintion). I think i'll need to revise my conventions for private properties usage, perhaps the strict way. http://fabien.potencier.org/article/47/pragmatism-over-theory-protected-vs-private ------------------------------------------------------------------------ [2012-05-05 09:12:45] g...@php.net No, I disagree with your premise. They are two different properties. Look at the output of the following program. This is a perfectly valid usecase and avoids name clashes. Yes, the visibility is here private and it makes semantically a difference. But still, defining a property with the same name in two classes in the same inheritance chain is always a code smell. And that is exactly what you are doing, since you got two 'use' declarations. I can see your desire to make it logically one, but that does not fit into the idea of flattening a trait into a class. <?php error_reporting(E_ALL); trait A { private $prop; } trait B { use A; } class FooT { use A; } class BarT extends FooT { use B; } class Foo { private $prop; } class Bar extends Foo { private $prop; } $o = new Bar; var_dump($o); $o = new BarT; var_dump($o); ------------------------------------------------------------------------ [2012-05-05 09:00:05] franssen dot roland at gmail dot com We can agree there's only 1 property definition right? The concrete classes Foo and Bar will never define that property since that would be a "real" conflict. So if you know that Bar::$prop is initially resolved from A::$prop as well as B::$prop you could say it's the same definition... Why i want this? I want to extend a package in a subpackage on class level as well as trait level. The concrete subpackage classes extend the corresponding package classes and i don't want to override the package trait functions in each subpackage concrete class so the subpackage comes with its own trait, build upon the package trait. It's really an architecture thing.. <?php namespace Base { trait MainTrait { public $prop; } class Main { use MainTrait; } } namespace Base\Sub { trait MainTrait { use \Base\MainTrait; } class Main extends \Base\Main { use MainTrait; } } ------------------------------------------------------------------------ [2012-05-04 23:28:50] g...@php.net Hi: >From my point of view, it is not the same property. My understanding is that you are moving here very much in the area of the typical diamond problem of multiple inheritance. Theoretically, it is not clear whether the two properties should be handled as the same or not. Why would you want to apply the trait a second time? Best regards Stefan ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=61943 -- Edit this bug report at https://bugs.php.net/bug.php?id=61943&edit=1
