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: 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 Previous Comments: ------------------------------------------------------------------------ [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 ------------------------------------------------------------------------ [2012-05-04 20:07:42] franssen dot roland at gmail dot com Description: ------------ Hi, (version is actually 5.4RC9...) The same property conflict happens when you have 2 traits (B uses A) where A defines the property, class Foo uses A and class Bar uses B _and_ extends Foo. I would love to see the strict standard to be removed in this situation; how can a property have a conflict with itself? Test script: --------------- <?php trait A { public $prop; } trait B { use A; } class Foo { use A; } class Bar extends Foo { use B; } Expected result: ---------------- <void> Actual result: -------------- Strict Standards: Foo and B define the same property ($prop) in the composition of Bar. This might be incompatible, to improve maintainability consider using accessor methods in traits instead. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=61943&edit=1
