Req #61943 [Com]: Trait same property conflict in class extending

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: E.g. something like; <?php trait A { } trait B { } class Foo { use A; } class Bar extends Foo { use B; } Previous Comments: ------------------------------------------------------------------------ [2012-05-05 11:50:41] franssen dot roland at gmail dot com Also i did'nt read your comment well, especially the "semantical difference" part.. ;-) ------------------------------------------------------------------------ [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] gron@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; } } ------------------------------------------------------------------------ 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