Traits and Properties

Hi Nathan:

Regarding visibility modifiers, why not carry them over from the trait directly, private in the trait definition results in private in the class definition.

The problem will be hopefully more clear in the following example:

trait StateMachineDoor {
private $currentState;
public function open() {....}
}

trait StateMachineElevator {
public $currentState;
public function callElevator() { ... }
}

These two traits are not compatible since currentState has different semantics in both traits.
With the current design of traits, there is no language solution to this problem.

The suggestions to avoid the problem are to use better names like $currentDoorState and $currentElevatorState, or to rely on accessors which is currently the only variant in which the programmer will notice that there is an incompatibility:

trait StateMachineDoor {
abstract function &getCurrentState();
public function open() {....}
}

trait StateMachineElevator {
abstract function &getCurrentState();
public function callElevator() { ... }
}

However, you might have a different situation, one where the traits are composable with respect to their state, i.e., they need to work on the same state:

trait OutputIterator {
public $array; // not sure why that is public here, but the implementor chose to make it public...
public function printNext() {...}
}

trait SortArray {
private $array; // this developer chose to make the array private, for what ever reason...
public function doSort() { ... }
}

I hope that makes the possible situations clear: state can either be composable or not, that really depends
on the trait. And there is no language solution for it build in at the moment.

So, back to my original question:

class SomethingOutputableAndSortable {
use OutoutIterator, SortArray;
}

What is the visibility of $array supposed to be in this class? private or public?

And further, in the very first example of this mail, ideally there should be some warning, however, that warning would be annoying for the last example, since here the state does not collide...

Best regards
Stefan

PS: there has been discussion on stateful traits before, but the language solutions to that where considered to complex.

--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525

Hi Sebastian:

And, to discorage users to go this way, should there be a STRICT
notice?

If you want to discourage attribute declaration in a trait, don't
allow it at all.
Not allowing it is not an option as far as I can tell.

You can always use dynamically defined properties in a method.
Changing that would change the whole character of PHP.
Then we would have two types of methods, methods that are defined in the class directly and can do what ever they want with properties, and methods from traits which are restricted and can't access any state.

I think, that would be to much penalty for all the valid use cases where a naive property usage in a trait is still just fine.

Best regards
Stefan

--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/

--

--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525

Hi Pierre:

hi,

Would it be possible to somehow document what you are discussing here?
It is not too easy to keep track of all discussions about traits
(along other things). Maybe in draft RFC or a simple page in the wiki.
Doing so will help to have a quick view about the open questions or
recent changes/propositions.
Yes, I try to keep track of all this in the RFC:
http://wiki.php.net/rfc/horizontalreuse?do=revisions

The current status of the property behavior is not yet documented explicitly, it is only implied since it is not handled at all...
And, it is the only open question that 'needs' to be solved since it is an inconsistency.
For instance the 'require Interface' is more like an additional feature.

Best regards
Stefan

Thanks!

Hi:

Traits do not provide any special provisioning for handling properties, especially, there is no language solution for handling colliding property names.
The current solution/idiom for handling state safely in a trait is to use either abstract set/get methods or an abstract get that returns a reference to the property in the class.

However, at the moment it is possible to define properties in a trait:

trait Foo {
private $a;
public $foo;
}

For the moment, that information is completely ignored, thus:

class Bar {
use Foo;
}
property_exists('Bar', 'a') === false

Well, and that is a rather inconsistent status-quo.

I would like to have that fixed in one or another way.

One possibility would be to forbid property definition in a trait altogether.
That reduces a bit the possibility to have wrong expectations about properties, however, the dynamic property creation is still possible.

Another way would be to merge the properties in the composing class.
The question here would be how to treat visibility modifiers: how to merge public and private, should it result in public, or private?
And, to discorage users to go this way, should there be a STRICT notice? Options here are a notice whenever a property is defined in a trait, or whenever properties are silently merged.

Comments very welcome.

Thanks
Stefan

--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525

--

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525

Hi Richard:

From the rfc [1], "A Trait is similar to a class, but only intended to
group functionality".

I'm guessing that says it all. A trait has no properties.

It is really a practical concern of language consistency for the moment.
I am not talking about any fancy new language feature to handle state.

At the moment, I am just concerned with examples like the following:

trait Foo {
function bar() {
$this->baz = 'abcd';
}
}

If that example becomes more complex, I would consider it to be good software engineering practice to document the usage of $this->baz and its semantic.

For classes this is usually done by explicitly naming the property in the class body.

At the moment, there is nothing which hinders you in doing that for a trait.

However, since traits do not provide any safety provisioning for state, i.e., there is no collision handling for properties, the question is, how do we either promote to use explicit accessors or how do we deal with the inevitable and certainly justified use of properties in one or the other way.

Best regards
Stefan

--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525

Am 16.12.2010 16:25, schrieb Stefan Marr:

From my point of view the right thing to do with regard to
properties is defined in the test cases below.

+1

--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/

I like it,

additionally if you want to prevent conflicts from the start you can
always go and define prefixed property names like below and use a getter to
access them conveniently.

trait Foo
{
private $Foo_prop;

public function getProp()
{
    return $this->Foo_prop;
}

}

I am really looking forward to traits in 5.4!

greetings,
Benjamin

On Thu, 16 Dec 2010 16:25:42 +0100, Stefan Marr php@stefan-marr.de
wrote:

Hi:

From my point of view the right thing to do with regard to properties is
defined in the test cases below.

The rational behind providing this semantics is based on the fact that
PHP
allows to define properties dynamically anyway, so there is no way
around
properties.
However, there should be a way that a developer can notice that the code
might not behave as expected in the composed class.

It is true that behavior needs state to operate on, however, accessors
are
a common pattern and fully supported by traits. Furthermore, traits are
not
supposed to replace classes, and when a trait does more than just
providing
code that is to be easily reused, then the designed should ask the
question
whether that is not actually a class, which then provides the necessary
guarantees to enforce the invariances the code expects.

Thus, I would like to keep traits as a lightweight concept for code
reuse.

Best regards
Stefan

--TEST--
Conflicting properties should result in a notice.
Property use is discorage for traits that are supposed to enable
maintainable
code reuse. Accessor methods are the language supported idiom for this.
--FILE--
<?php
error_reporting(E_ALL);

trait THello1 {
public $foo;
}

trait THello2 {
private $foo;
}

class TraitsTest {
use THello1;
use THello2;
}

var_dump(property_exists('TraitsTest', 'foo'));
?>
--EXPECTF--
Notice: Trait THello1 and THello2 define the same property in the
composition of TraitsTest. This might be incompatible, to improve
maintainability consider using accessor methods instead. Class was
composed
in %s on line %d.

bool(true)

--TEST--
Non-conflicting properties should work just fine.
--FILE--
<?php
error_reporting(E_ALL);

trait THello1 {
public $hello = "hello";
}

trait THello2 {
private $world = "World!";
}

class TraitsTest {
use THello1;
use THello2;
function test() {
echo $this->hello . ' ' . $this->world;
}
}

var_dump(property_exists('TraitsTest', 'hello'));
var_dump(property_exists('TraitsTest', 'world'));

$t = new TraitsTest;
$t->test();
?>
--EXPECTF--
bool(true)
bool(true)

hello World!

--TEST--
Conflicting properties with different visibility modifiers should be
merged
to the most restrictive modifier.
--FILE--
<?php
error_reporting(E_ALL);

trait THello1 {
public $hello;
}

trait THello2 {
private $hello;
}

class TraitsTest {
use THello1;
use THello2;
}

$t = new TraitsTest;
$t->hello = "foo";
?>
--EXPECTF--
Fatal error: Cannot access private property TraitsTest::$foo in %s on
line
%d

Hi:

Traits do not provide any special provisioning for handling properties,
especially, there is no language solution for handling colliding
property
names.
The current solution/idiom for handling state safely in a trait is to
use either abstract set/get methods or an abstract get that returns a
reference to the property in the class.

However, at the moment it is possible to define properties in a trait:

trait Foo {
private $a;
public $foo;
}

For the moment, that information is completely ignored, thus:

class Bar {
use Foo;
}
property_exists('Bar', 'a') === false

Well, and that is a rather inconsistent status-quo.

I would like to have that fixed in one or another way.

One possibility would be to forbid property definition in a trait
altogether.
That reduces a bit the possibility to have wrong expectations about
properties, however, the dynamic property creation is still possible.

Another way would be to merge the properties in the composing class.
The question here would be how to treat visibility modifiers: how to
merge public and private, should it result in public, or private?
And, to discorage users to go this way, should there be a STRICT
notice?
Options here are a notice whenever a property is defined in a trait, or
whenever properties are silently merged.

Comments very welcome.

Thanks
Stefan

--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525

--

--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525

From my point of view the right thing to do with regard to properties
is defined in the test cases below.

The rational behind providing this semantics is based on the fact that
PHP allows to define properties dynamically anyway, so there is no way
around properties. However, there should be a way that a developer
can notice that the code might not behave as expected in the composed
class.

+1

The test cases you include are exactly how I would expect traits to work
with regards to properties.

--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

2010/12/16 Stefan Marr php@stefan-marr.de:

Hi:

From my point of view the right thing to do with regard to properties is defined in the test cases below.

The rational behind providing this semantics is based on the fact that PHP allows to define properties dynamically anyway, so there is no way around properties.
However, there should be a way that a developer can notice that the code might not behave as expected in the composed class.

It is true that behavior needs state to operate on, however, accessors are a common pattern and fully supported by traits. Furthermore, traits are not supposed to replace classes, and when a trait does more than just providing code that is to be easily reused, then the designed should ask the question whether that is not actually a class, which then provides the necessary guarantees to enforce the invariances the code expects.

Thus, I would like to keep traits as a lightweight concept for code reuse.

Best regards
Stefan

--TEST--
Conflicting properties should result in a notice.
Property use is discorage for traits that are supposed to enable maintainable
code reuse. Accessor methods are the language supported idiom for this.
--FILE--
<?php
error_reporting(E_ALL);

trait THello1 {
 public $foo;
}

trait THello2 {
 private $foo;
}

class TraitsTest {
       use THello1;
       use THello2;
}

var_dump(property_exists('TraitsTest', 'foo'));
?>
--EXPECTF--
Notice: Trait THello1 and THello2 define the same property in the composition of TraitsTest. This might be incompatible, to improve maintainability consider using accessor methods instead. Class was composed in %s on line %d.

In this test, you might want to display some text before the
var_dump() (or alternatively to hardcode the line number on last line)
to ensure it is the property_exists() function call or the class
definition which would create such a notice.

Regards,
Patrick

--
Patrick Allaert

http://code.google.com/p/peclapm/ - Alternative PHP Monitor

I am fine with this approach, with 2 caveats:

• If you actually do want to make two traits use the same property, it
  looks like the answer here is "Either have no property and demand the
  existence of an accessor that returns by reference, or you can't write
  E_NOTICE-safe code". Is that true?

• When the visibility collides, should we be folding to the most
  restrictive or least restrictive? I'm not sure myself; I'm more
  interested in your reasoning for going for most-restrictive.

--Larry Garfield

Hi:

From my point of view the right thing to do with regard to properties is defined in the test cases below.

The rational behind providing this semantics is based on the fact that PHP allows to define properties dynamically anyway, so there is no way around properties.
However, there should be a way that a developer can notice that the code might not behave as expected in the composed class.

It is true that behavior needs state to operate on, however, accessors are a common pattern and fully supported by traits. Furthermore, traits are not supposed to replace classes, and when a trait does more than just providing code that is to be easily reused, then the designed should ask the question whether that is not actually a class, which then provides the necessary guarantees to enforce the invariances the code expects.

Thus, I would like to keep traits as a lightweight concept for code reuse.

Best regards
Stefan

--TEST--
Conflicting properties should result in a notice.
Property use is discorage for traits that are supposed to enable maintainable
code reuse. Accessor methods are the language supported idiom for this.
--FILE--
<?php
error_reporting(E_ALL);

trait THello1 {
public $foo;
}

trait THello2 {
private $foo;
}

class TraitsTest {
use THello1;
use THello2;
}

var_dump(property_exists('TraitsTest', 'foo'));
?>
--EXPECTF--
Notice: Trait THello1 and THello2 define the same property in the composition of TraitsTest. This might be incompatible, to improve maintainability consider using accessor methods instead. Class was composed in %s on line %d.

bool(true)

--TEST--
Non-conflicting properties should work just fine.
--FILE--
<?php
error_reporting(E_ALL);

trait THello1 {
public $hello = "hello";
}

trait THello2 {
private $world = "World!";
}

class TraitsTest {
use THello1;
use THello2;
function test() {
echo $this->hello . ' ' . $this->world;
}
}

var_dump(property_exists('TraitsTest', 'hello'));
var_dump(property_exists('TraitsTest', 'world'));

$t = new TraitsTest;
$t->test();
?>
--EXPECTF--
bool(true)
bool(true)

hello World!

--TEST--
Conflicting properties with different visibility modifiers should be merged
to the most restrictive modifier.
--FILE--
<?php
error_reporting(E_ALL);

trait THello1 {
public $hello;
}

trait THello2 {
private $hello;
}

class TraitsTest {
use THello1;
use THello2;
}

$t = new TraitsTest;
$t->hello = "foo";
?>
--EXPECTF--
Fatal error: Cannot access private property TraitsTest::$foo in %s on line %d

Hi:

Traits do not provide any special provisioning for handling properties, especially, there is no language solution for handling colliding property names.
The current solution/idiom for handling state safely in a trait is to use either abstract set/get methods or an abstract get that returns a reference to the property in the class.

However, at the moment it is possible to define properties in a trait:

trait Foo {
private $a;
public $foo;
}

For the moment, that information is completely ignored, thus:

class Bar {
use Foo;
}
property_exists('Bar', 'a') === false

Well, and that is a rather inconsistent status-quo.

I would like to have that fixed in one or another way.

One possibility would be to forbid property definition in a trait altogether.
That reduces a bit the possibility to have wrong expectations about properties, however, the dynamic property creation is still possible.

Another way would be to merge the properties in the composing class.
The question here would be how to treat visibility modifiers: how to merge public and private, should it result in public, or private?
And, to discorage users to go this way, should there be a STRICT notice? Options here are a notice whenever a property is defined in a trait, or whenever properties are silently merged.

Comments very welcome.

Thanks
Stefan

--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525

Hi:

Traits do not provide any special provisioning for handling properties,
especially, there is no language solution for handling colliding property names.
The current solution/idiom for handling state safely in a trait is to use either
abstract set/get methods or an abstract get that returns a reference to the
property in the class.

However, at the moment it is possible to define properties in a trait:

trait Foo {
private $a;
public $foo;
}

For the moment, that information is completely ignored, thus:

class Bar {
use Foo;
}
property_exists('Bar', 'a') === false

Well, and that is a rather inconsistent status-quo.

I would like to have that fixed in one or another way.

One possibility would be to forbid property definition in a trait altogether.
That reduces a bit the possibility to have wrong expectations about properties,
however, the dynamic property creation is still possible.

Another way would be to merge the properties in the composing class.
The question here would be how to treat visibility modifiers: how to merge
public and private, should it result in public, or private?
And, to discorage users to go this way, should there be a STRICT notice? Options
here are a notice whenever a property is defined in a trait, or whenever
properties are silently merged.

Comments very welcome.

Thanks
Stefan

What about extending the way that traits resolve method conflicts to solve
property conflicts in a similar fashion? I can't remember if it's already been
suggested and and maybe shot down already. It would probably get horrendously
messy, but figured I'd mention it anyway.

Cheers,
David

I'm a latecomer here, but...

Stefan, doesn't this conflict with what you've written here (and the
test cases in SVN)?:

http://wiki.php.net/rfc/horizontalreuse#handling_of_propertiesstate

Or is what is happening here that the properties in traits are treated
essentially as declarations rather than definitions, triggering errors
but not actually creating properties, and you think they should actually
create properties?

Ben.