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] 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; }
}
------------------------------------------------------------------------
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
