Electronics & Programming

develissimo

Open Source electronics development and programming

  • You are not logged in.
  • Root
  • » PHP
  • » [PHP-DEV] Traits and Properties [RSS Feed]

#1 Dec. 11, 2010 18:36:28

Nathan N.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Traits and Properties


On Sat, Dec 11, 2010 at 9:47 AM, Stefan Marr <p...@stefan-marr.de> wrote:

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

I would prefer they be definable within traits and merged into classes,
otherwise traits will not have the chance to be self-contained entities of
reusable logic. Also, I think merging them in is consistent with the
treatment given to methods as they pertain to traits.

As I'm sure you know:
<?php
class A {
use SomeTrait;
}

trait SomeTrait {
public function traitMethod() {}
}

method_exists('A', 'traitMethod') === true;
?>

Regarding visibility modifiers, why not carry them over from the trait
directly, private in the trait definition results in private in the class
definition. Lastly, I'm not sure why you would want to discourage this
usage, I would plan on adding properties in traits myself.

-nathan

Offline

#2 Dec. 11, 2010 18:37:30

Sebastian B.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Traits and Properties


On 12/11/2010 05:47 PM, Stefan Marr wrote:Another way would be to merge the properties in the composing class.+1The question here would be how to treat visibility modifiersOne option would be to only allow private. That way only methods from
the trait would have access and collisions could be prevented.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.

--
Sebastian Bergmann Co-Founder and Principal Consultanthttp://sebastian-bergmann.de/http://thePHP.cc/--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#3 Dec. 11, 2010 22:13:58

Pierre J.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Traits and Properties


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.

Thanks!

On Sat, Dec 11, 2010 at 5:47 PM, Stefan Marr <p...@stefan-marr.de> wrote:
> 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
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit:http://www.php.net/unsub.php>
>



--
Pierre

@pierrejoye |http://blog.thepimp.net|http://www.libgd.org--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#4 Dec. 11, 2010 23:33:04

Stefan M.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Traits and Properties


Hi Pierre:

On 11 Dec 2010, at 23:13, Pierre Joye wrote:

> 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=revisionsThe 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!
>
> On Sat, Dec 11, 2010 at 5:47 PM, Stefan Marr <p...@stefan-marr.de> wrote:
>> 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
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit:http://www.php.net/unsub.php>>
>>
>
>
>
> --
> Pierre
>
> @pierrejoye |http://blog.thepimp.net|http://www.libgd.org--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgiumhttp://soft.vub.ac.be/~smarrPhone: +32 2 629 2974
Fax: +32 2 629 3525


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#5 Dec. 12, 2010 00:25:15

Stefan M.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Traits and Properties


Hi Sebastian:

On 11 Dec 2010, at 19:36, Sebastian Bergmann wrote:
>> 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/>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit:http://www.php.net/unsub.php>

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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#6 Dec. 12, 2010 09:03:32

Sebastian B.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Traits and Properties


On 12/12/2010 01:24 AM, Stefan Marr wrote: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.Good! :-)

--
Sebastian Bergmann Co-Founder and Principal Consultanthttp://sebastian-bergmann.de/http://thePHP.cc/--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#7 Dec. 12, 2010 11:01:36

Stefan M.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Traits and Properties


Hi Nathan:

On 11 Dec 2010, at 19:35, Nathan Nobbe wrote:

> 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 / Belgiumhttp://soft.vub.ac.be/~smarrPhone: +32 2 629 2974
Fax: +32 2 629 3525


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#8 Dec. 13, 2010 13:14:28

Richard Q.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Traits and Properties


On 11 December 2010 16:47, Stefan Marr <p...@stefan-marr.de> wrote:
> 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

>From the rfc , "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.

But.

If properties are to be added to a trait, I think that should come as
a further enhancement and let traits start out as "methods only".

If a trait is properties, then also supporting constants and the other
sort of set/get properties would provide a strong level of
consistency. If I can put it in a class, I can put it in a trait.

As visibility on the traits methods can be manipulated via the
aliasing mechanism, so should any visibility to a property.

Richard.

http://wiki.php.net/rfc/horizontalreuse--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#9 Dec. 13, 2010 13:34:28

Richard Q.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Traits and Properties


On 11 December 2010 23:31, Stefan Marr <p...@stefan-marr.de> wrote:
> The current status of the property behavior is not yet documented explicitly

On the assumption that traits WILL include properties (with
visibility) and aliasing can do all its magic, how would the situation
be handled where multiple traits define shared properties.

I've not got a use case, but say trait1 and trait2 both define the
same property.

Assuming name conflicts are handled via aliasing, then the property
needs to alert the aliasing code that this property is a non
conflicting property. All traits wanting to access the shared property
would have to reveal their intentions.

I can think of 2 ways to handle this (but I'm no genius here, so take
them apart at your pleasure).

1 - The trait's code marks shared properties with a keyword (shared,
common, virtual, something). During incorporation of the trait into
the main class, any marked properties are checked for visibility only.
2 - The trait's code uses a &$property. The fact that this is a
reference would require the creation of the property (if it doesn't
already exist) whilst the trait is being compiled into the main class.
I'd guess this would be the least difficult to implement, but I know
squat about this.

I'm guessing the order of handling the traits would be significant here.

Trait1 uses $property, Trait2 uses $property - conflict. Must be
resolved by aliasing or an error.
Trait1 uses &$property, Trait2 uses &$property - all ok. Trait1 wants
access a non existing property, so one is created. Trait2 is sharing
the now pre-existing property.
Trait1 uses &$property, Trait2 uses $property - conflict. Trait1 wants
access a non existing property, so one is created. Trait2's $property
must be aliased to an error.
Trait1 uses $property, Trait2 uses &$property - all ok. Trait1's
$property is added as expected. Trait2 is sharing the now pre-existing
property.

Richard.


--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#10 Dec. 13, 2010 16:03:13

Stefan M.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Traits and Properties


Hi Richard:

On 13 Dec 2010, at 14:13, Richard Quadling wrote:

> From the rfc , "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 / Belgiumhttp://soft.vub.ac.be/~smarrPhone: +32 2 629 2974
Fax: +32 2 629 3525


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

  • Root
  • » PHP
  • » [PHP-DEV] Traits and Properties [RSS Feed]

Board footer

Moderator control

Enjoy the 11th of December
PoweredBy

The Forums are managed by develissimo stuff members, if you find any issues or misplaced content please help us to fix it. Thank you! Tell us via Contact Options
Leave a Message
Welcome to Develissimo Live Support