5.4a2 trait attribute name conflict resolution

13 years ago by Alex Howansky — view source

unread

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

13 years ago by Richard Quadling — view source

unread

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

13 years ago by Michael Stowe — view source

unread

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 ---

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

13 years ago by Anthony Ferrara — view source

unread

I was under the impression that traits were not supposed to have
properties at all:

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?

Thanks,

--
Alex Howansky

13 years ago by Jonathan Bond-Caron — view source

unread

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=markup&pathrev=306476

If the modifier is different/conflicting (public, protected, private)
E_FATAL
http://svn.php.net/viewvc?view=revision&revision=306476
http://marc.info/?l=php-internals&m=129251322332367&w=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?

13 years ago by Alex Howansky — view source

unread

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

13 years ago by Jonathan Bond-Caron — view source

unread

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)

13 years ago by Stefan Marr — view source

unread

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

13 years ago by Mike Stowe — view source

unread

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

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

13 years ago by Stefan Marr — view source

unread

Hi Mike:

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

13 years ago by Stefan Marr — view source

unread

Hi Alex:

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

13 years ago by Stefan Marr — view source

unread

Hi:

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=revision&revision=313632

Best regards
Stefan

13 years ago by Alex Howansky — view source

unread

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

13 years ago by Adam Harvey — view source

unread

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

13 years ago by Michael Stowe — view source

unread

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

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

13 years ago by Alex Howansky — view source

unread

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

13 years ago by Philip Olson — view source

unread

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=trait&cmd=display

Regards,
Philip

13 years ago by Anthony Ferrara — view source

unread

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

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