Re: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
Hi:
On Fri, Jul 22, 2011 at 5:17 PM, Alex Howansky alex.howan...@gmail.com wrote:
Hello folks,
I've just grabbed 5.4a2 to play with traits. I've found some behaviour which
I'm not sure is a bug, an inconsistency, or a design decision.
Consider a trait and a class that implements it but also overrides both a
trait method and a trait attribute:
trait foo
{
public $zoo = 'foo::zoo';
public function bar()
{
echo in foo::bar\n;
}
}
class baz
{
use foo;
public $zoo = 'baz::zoo';
public function bar()
{
echo in baz::bar\n;
}
}
$obj = new baz();
$obj-bar();
echo $obj-zoo, \n;
We get:
in baz::bar
foo::zoo
It seems this is not correct and that it should be:
in baz::bar
baz::zoo
After some more thought, my take on this is that those properties are
not compatible, and we do the only simple thing possible and raise an
error as soon as possible, because the trait might have changed to
something that is not compatible with the class and the developer has
to be made aware of that.
While traits do not support state per se, we defined a minimal set of
rules so that the use of properties which conflict in their semantics
breaks as early as possible and noticeable to the developer.
Please refer to
https://wiki.php.net/rfc/horizontalreuse?#handling_of_propertiesstate
for the exact set of rules defined currently.
These rules (rule 1) define that properties are considered
incompatible if they differ in their initial value.
Thus, the case you see here is, according to the rules defined in the
RFC, a bug.
And after looking at the implementation, it turns out that I just
forgot to check one of the return values of the compare function.
Thus, this is fixed as per
http://svn.php.net/viewvc?view=revisionrevision=313632
Best regards
Stefan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
Hi Alex: On Fri, Jul 22, 2011 at 7:46 PM, Alex Howansky alex.howan...@gmail.com wrote: Best practice, always choose trait property names carefully/~unique so that you don't run into conflicts. Sure, but in this case, I created the conflict intentionally because I *want* to override it, and I'm not allowed to like I am with methods. Don't you think that's inconsistent? The short answer is it's not a bug but maybe an implementation issue... should it be an E_WARNING instead of E_STRICT? At least. Consider the situation where I'm using classes/traits from somebody else's library that I may not be intimately familiar with. I'll have to know what every one of their properties is named so I can plan my code accordingly -- else I'll silently start getting their values in what I think are my variables. If their trait grows that complex, with its own set of invariants, it is a clear sign that it should be a class instead. Traits are supposed to be a very light-weight mechanism for reuse of behavior. Classes already provide you with the necessary means of encapsulation you are asking for here: but traits do not do that. If you want to reuse a trait that is that complex, consider to use it in a separate class, which is then used in a composition in the class were you originally were going to use the trait directly. Traits do not allow to be reused without knowing their internals. The metaphor of a compiler-assisted copy'n'past mechanism hints at that. At least that is my interpretation of the topic. Best regards Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
On Fri, Jul 22, 2011 at 8:41 PM, Jonathan Bond-Caron jbo...@openmv.com wrote: On Fri Jul 22 01:46 PM, Alex Howansky wrote: Sure, but in this case, I created the conflict intentionally because I *want* to override it, and I'm not allowed to like I am with methods. Don't you think that's inconsistent? Agree I do not agree, because for methods there is for most cases a way around. You can introduce a new alias for the same behavior and use that from the method which is overriding the original method name of the trait. Thus, there is a flexible way to compose behavior, and that is what we do everyday. State how ever, does not come with that property, and the last time we discussed different ideas in that direction they were deemed to be complex. So that traits can keep their own private state (Ben Schmidt's idea) One of those ideas should definitely be reconsidered for a later version of PHP, but for the moment, I would prefer to concentrate on getting bug-free what we have already and gather some experience on how it is actually used in real-world scenarios. In the end, if you trait is to complex and can 'break' easily, I think that shows that it is worth to be implemented as a class, and you might use instead a trait that provides you with the necessary delegation functions. Best regards Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
So am I understanding correctly that the initial properties must be identical both in type and value, otherwise it would throw an error. To me that would make the most sense as they could be overridden in a construct or other method. If they are allowed to be different with one overriding the other- than for usability the class should override the trait properties as it does with methods. This way it remains consistent, which I think would be the general expectation. The trait should likewise override the parent class properties as it does with the parent methods (unless I misread that). But essentially if they're allowed to be different the overriding pattern IMHO should be the same as that used for methods. - Mike :o) Sent from my iPhone On Jul 23, 2011, at 8:58 AM, Stefan Marr p...@stefan-marr.de wrote: On Fri, Jul 22, 2011 at 8:41 PM, Jonathan Bond-Caron jbo...@openmv.com wrote: On Fri Jul 22 01:46 PM, Alex Howansky wrote: Sure, but in this case, I created the conflict intentionally because I *want* to override it, and I'm not allowed to like I am with methods. Don't you think that's inconsistent? Agree I do not agree, because for methods there is for most cases a way around. You can introduce a new alias for the same behavior and use that from the method which is overriding the original method name of the trait. Thus, there is a flexible way to compose behavior, and that is what we do everyday. State how ever, does not come with that property, and the last time we discussed different ideas in that direction they were deemed to be complex. So that traits can keep their own private state (Ben Schmidt's idea) One of those ideas should definitely be reconsidered for a later version of PHP, but for the moment, I would prefer to concentrate on getting bug-free what we have already and gather some experience on how it is actually used in real-world scenarios. In the end, if you trait is to complex and can 'break' easily, I think that shows that it is worth to be implemented as a class, and you might use instead a trait that provides you with the necessary delegation functions. Best regards Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
Hi Mike: On Sat, Jul 23, 2011 at 6:49 PM, Mike Stowe mikegst...@gmail.com wrote: So am I understanding correctly that the initial properties must be identical both in type and value, otherwise it would throw an error. To me that would make the most sense as they could be overridden in a construct or other method. Yes, they have to be perfectly identical. Any difference indicates, in this strict model, a potential conflict and different semantics of that particular property i.e. the state. Since we do not provide any means to manage such conflicts, we bail out as early as possible and ask the programmer to fix his code by ensuring everything is compatible. Best regards Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 5.4a2 trait attribute name conflict resolution
Hello folks,
I've just grabbed 5.4a2 to play with traits. I've found some behaviour
which I'm not sure is a bug, an inconsistency, or a design decision.
Consider a trait and a class that implements it but also overrides both
a trait method and a trait attribute:
trait foo
{
public $zoo = 'foo::zoo';
public function bar()
{
echo in foo::bar\n;
}
}
class baz
{
use foo;
public $zoo = 'baz::zoo';
public function bar()
{
echo in baz::bar\n;
}
}
$obj = new baz();
$obj-bar();
echo $obj-zoo, \n;
We get:
in baz::bar
foo::zoo
It seems this is not correct and that it should be:
in baz::bar
baz::zoo
The traits RFC pretty clearly states that if a class method conflicts
with a trait method then the trait method will be ignored, which is
what's happening, but it says nothing about what happens to attributes
in that same condition. Is this a bug?
Thanks,
--
Alex Howansky
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
I was under the impression that traits were not supposed to have
properties at all:
From the RFC:
Since Traits do not contain any state/properties, there is a need to
describe the requirements a Trait will rely on. In PHP it would be
possible to utilize the dynamic language features, but it is a common
practice to give this requirements explicitly. This is possible with
abstract methods like it is used for abstract classes.
Is the support for properties the bug perhaps?
Anthony
On Fri, Jul 22, 2011 at 11:17 AM, Alex Howansky alex.howan...@gmail.com wrote:
Hello folks,
I've just grabbed 5.4a2 to play with traits. I've found some behaviour which
I'm not sure is a bug, an inconsistency, or a design decision.
Consider a trait and a class that implements it but also overrides both a
trait method and a trait attribute:
trait foo
{
public $zoo = 'foo::zoo';
public function bar()
{
echo in foo::bar\n;
}
}
class baz
{
use foo;
public $zoo = 'baz::zoo';
public function bar()
{
echo in baz::bar\n;
}
}
$obj = new baz();
$obj-bar();
echo $obj-zoo, \n;
We get:
in baz::bar
foo::zoo
It seems this is not correct and that it should be:
in baz::bar
baz::zoo
The traits RFC pretty clearly states that if a class method conflicts with a
trait method then the trait method will be ignored, which is what's
happening, but it says nothing about what happens to attributes in that same
condition. Is this a bug?
Thanks,
--
Alex Howansky
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
On 22 July 2011 16:17, Alex Howansky alex.howan...@gmail.com wrote:
Hello folks,
I've just grabbed 5.4a2 to play with traits. I've found some behaviour which
I'm not sure is a bug, an inconsistency, or a design decision.
Consider a trait and a class that implements it but also overrides both a
trait method and a trait attribute:
trait foo
{
public $zoo = 'foo::zoo';
public function bar()
{
echo in foo::bar\n;
}
}
class baz
{
use foo;
public $zoo = 'baz::zoo';
public function bar()
{
echo in baz::bar\n;
}
}
$obj = new baz();
$obj-bar();
echo $obj-zoo, \n;
We get:
in baz::bar
foo::zoo
It seems this is not correct and that it should be:
in baz::bar
baz::zoo
The traits RFC pretty clearly states that if a class method conflicts with a
trait method then the trait method will be ignored, which is what's
happening, but it says nothing about what happens to attributes in that same
condition. Is this a bug?
Thanks,
--
Alex Howansky
In my limited understanding, a trait is sort of composited at compile
time (ish). As properties are dynamic (ish), they will overwrite. Just
like an inherited class will overwrite public properties in their
parent class.
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
That makes sense if it would overwrite the methods as well, but otherwise it seems like it provides inconsistent functionality. Exactly. At the least, it's inconsistent. If it's a bug, then it seems the question becomes: Is the bug this: Properties defined in a trait should be overridden by same-named properties defined in a class that use the trait. Or (as pointed out by Anthony) this: You shouldn't be able to define properties in a trait. -- Alex Howansky smime.p7s Description: S/MIME Cryptographic Signature
Re: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
On 22 July 2011 09:12, Alex Howansky alex.howan...@gmail.com wrote: That makes sense if it would overwrite the methods as well, but otherwise it seems like it provides inconsistent functionality. Exactly. At the least, it's inconsistent. If it's a bug, then it seems the question becomes: Is the bug this: Properties defined in a trait should be overridden by same-named properties defined in a class that use the trait. Or (as pointed out by Anthony) this: You shouldn't be able to define properties in a trait. Traits definitely need to be able to support properties, IMO, so I'd say that the first behaviour just needs to be documented (and potentially a notice added). Either the trait or the class is going to have its property overwritten, so we should pick which definition wins and go from there. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
I agree with Adam, I think it would be nice to let the trait contain its own properties which can then be overwritten by the class properties. This way we could include default properties that the trait may be dependent on, while providing the opportunity to override individual properties to provide a specific reaction for the class the trait is used in. Just curious, if the trait property is set to private what happens? - Mike On Fri, Jul 22, 2011 at 11:18 AM, Adam Harvey ahar...@php.net wrote: On 22 July 2011 09:12, Alex Howansky wrote: That makes sense if it would overwrite the methods as well, but otherwise it seems like it provides inconsistent functionality. Exactly. At the least, it's inconsistent. If it's a bug, then it seems the question becomes: Is the bug this: Properties defined in a trait should be overridden by same-named properties defined in a class that use the trait. Or (as pointed out by Anthony) this: You shouldn't be able to define properties in a trait. Traits definitely need to be able to support properties, IMO, so I'd say that the first behaviour just needs to be documented (and potentially a notice added). Either the trait or the class is going to have its property overwritten, so we should pick which definition wins and go from there. Adam -- --- My command is this: Love each other as I have loved you. John 15:12 ---
Re: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
Traits definitely need to be able to support properties, IMO Well, if traits support properties, they stop being traits and become mixins. A trait is nothing more than a mixin that does not have a state (so no properties). I'm not saying that it wouldn't be useful to contain properties (and hence state), but the RFC was for traits, they are called traits, and the RFC does mention that they shouldn't contain state. So a trait (by definition) should be purely behavioral (methods only). So, based on that, it does indeed seem like a bug to me that they currently support properties. If properties are to be supported, then why don't we rename the trait to a mixin and have some semblance of consistency... Anthony On Fri, Jul 22, 2011 at 12:18 PM, Adam Harvey ahar...@php.net wrote: On 22 July 2011 09:12, Alex Howansky alex.howan...@gmail.com wrote: That makes sense if it would overwrite the methods as well, but otherwise it seems like it provides inconsistent functionality. Exactly. At the least, it's inconsistent. If it's a bug, then it seems the question becomes: Is the bug this: Properties defined in a trait should be overridden by same-named properties defined in a class that use the trait. Or (as pointed out by Anthony) this: You shouldn't be able to define properties in a trait. Traits definitely need to be able to support properties, IMO, so I'd say that the first behaviour just needs to be documented (and potentially a notice added). Either the trait or the class is going to have its property overwritten, so we should pick which definition wins and go from there. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
Didn't send to list the first time, please accept my apologies if you
received this twice - Thanks
That makes sense if it would overwrite the methods as well, but otherwise it
seems like it provides inconsistent functionality. Perhaps I'm wrong as
likewise I have a very limited understanding here.
- Mike
-- Past Conversation ---
-
In my limited understanding, a trait is sort of composited at compile
time (ish). As properties are dynamic (ish), they will overwrite. Just
like an inherited class will overwrite public properties in their
parent class.
Richard
-
I was under the impression that traits were not supposed to have
properties at all:
From the RFC:
Since Traits do not contain any state/properties, there is a need to
describe the requirements a Trait will rely on. In PHP it would be
possible to utilize the dynamic language features, but it is a common
practice to give this requirements explicitly. This is possible with
abstract methods like it is used for abstract classes.
Is the support for properties the bug perhaps?
Anthony
-
Hello folks,
I've just grabbed 5.4a2 to play with traits. I've found some behaviour which
I'm not sure is a bug, an inconsistency, or a design decision.
Consider a trait and a class that implements it but also overrides both a
trait method and a trait attribute:
trait foo
{
public $zoo = 'foo::zoo';
public function bar()
{
echo in foo::bar\n;
}
}
class baz
{
use foo;
public $zoo = 'baz::zoo';
public function bar()
{
echo in baz::bar\n;
}
}
$obj = new baz();
$obj-bar();
echo $obj-zoo, \n;
We get:
in baz::bar
foo::zoo
It seems this is not correct and that it should be:
in baz::bar
baz::zoo
The traits RFC pretty clearly states that if a class method conflicts with a
trait method then the trait method will be ignored, which is what's
happening, but it says nothing about what happens to attributes in that same
condition. Is this a bug?
Alex
Re: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
Just curious, if the trait property is set to private what happens? Ooh, good question. PHP Fatal error: baz and foo define the same property ($zoo) in the composition of baz. However, the definition differs and is considered incompatible. -- Alex Howansky smime.p7s Description: S/MIME Cryptographic Signature
RE: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
On Fri Jul 22 11:17 AM, Alex Howansky wrote:
trait foo
{
public $zoo = 'foo::zoo';
public function bar()
{
echo in foo::bar\n;
}
}
class baz
{
use foo;
public $zoo = 'baz::zoo';
public function bar()
{
echo in baz::bar\n;
}
}
$obj = new baz();
$obj-bar();
echo $obj-zoo, \n;
We get:
in baz::bar
foo::zoo
It seems this is not correct and that it should be:
in baz::bar
baz::zoo
The expected behavior is an E_STRICT notice:
http://svn.php.net/viewvc/php/php-src/trunk/Zend/tests/traits/property001.ph
pt?view=markuppathrev=306476
If the modifier is different/conflicting (public, protected, private)
E_FATAL
http://svn.php.net/viewvc?view=revisionrevision=306476
http://marc.info/?l=php-internalsm=129251322332367w=2
The theory is traits should not have conflicting state/properties.
Best practice, always choose trait property names carefully/~unique so that
you don't run into conflicts.
The short answer is it's not a bug but maybe an implementation issue...
should it be an E_WARNING instead of E_STRICT?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
On Jul 22, 2011, at 9:32 AM, Alex Howansky wrote: Just curious, if the trait property is set to private what happens? Ooh, good question. PHP Fatal error: baz and foo define the same property ($zoo) in the composition of baz. However, the definition differs and is considered incompatible. And while people have traits on the mind, please also review the three open bug reports which also discuss how trait behavior should be defined: https://bugs.php.net/search.php?search_for=traitcmd=display Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
Best practice, always choose trait property names carefully/~unique so that you don't run into conflicts. Sure, but in this case, I created the conflict intentionally because I *want* to override it, and I'm not allowed to like I am with methods. Don't you think that's inconsistent? The short answer is it's not a bug but maybe an implementation issue... should it be an E_WARNING instead of E_STRICT? At least. Consider the situation where I'm using classes/traits from somebody else's library that I may not be intimately familiar with. I'll have to know what every one of their properties is named so I can plan my code accordingly -- else I'll silently start getting their values in what I think are my variables. -- Alex Howansky smime.p7s Description: S/MIME Cryptographic Signature
RE: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
On Fri Jul 22 01:46 PM, Alex Howansky wrote:
Sure, but in this case, I created the conflict intentionally because I
*want* to override it, and I'm not allowed to like I am with methods.
Don't you think that's inconsistent?
Agree
The short answer is it's not a bug but maybe an implementation
issue... should it be an E_WARNING instead of E_STRICT?
At least. Consider the situation where I'm using classes/traits from
somebody else's library that I may not be intimately familiar with.
I'll have to know what every one of their properties is named so I can
plan my code accordingly -- else I'll silently start getting their
values in what I think are my variables.
Part of the problem is if you have something like:
trait foo
{
private $zoo = 'important_do_not_modify';
public function showZoo(){
echo $this-zoo;
}
public function doSomething(){
if($this-zoo !== 'important_do_not_modify') die('bad');
}
}
class baz
{
use foo;
private $zoo = 'modified';
}
$obj = new baz();
$obj-bar();
echo $obj-showZoo(); // modified
echo $obj-doSomething();
You can essentially 'break' the trait. So if you think of using someone
else's library/trait, it's not fun either when you break something without
knowing it.
But even then, I'm with you on allowing to change the default property value
in the composing class (I'm in favor of it).
What traits would likely need is:
trait foo
{
trait $zoo = 'important_do_not_modify';
public function doSomething(){
if(trait::$zoo !== 'important_do_not_modify') die('bad');
}
}
So that traits can keep their own private state (Ben Schmidt's idea)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
