Re: [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 BergmannCo-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
Re: [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 / 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
RE: [PHP-DEV] Traits expecting interfaces implicitly leads to expensive runtime checks
On Sat Dec 11 10:25 AM, Stefan Marr wrote:
http://wiki.php.net/rfc/horizontalreuse#requiring_composing_class_to_impleme
nt_interface
Are there any objections to implementing this?
It's not a bad idea, though I haven't found a strong need for it in the way
I plan to use traits.
It also turns a trait into something more complex 'copy paste' code with
requirements/dependencies.
-1 on using 'require' (T_REQUIRE token), an option could be 'within'
trait IteratorUser within Iterator {
function foo() {
$next = $this-next();
...
}
}
class MyIterator implements Iterator {
with IteratorUser;
}
So the 'with/within' tokens would apply to traits.
Overall I feel -1, more use cases around Trait expresses a requirement for
the composing class would help, it seems like useful theory... not
convinced it's worth the trouble.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: ts_free_thread() frees only temporary in multiple parallel threads
(Referring to my posts: #50838 and #50916) Well although I got the feeling no one cares, I finally found a solution to my problem!!! Combining my patch (from post #50916) with the php_embed2 module makes everything working great in multi-threaded usage. The normal php_embed module does not seem to be designed for that. So my final conclusion for the multi-threaded SAPI is the following: - my patch is needed (to avoid false resource allocation) - php_embed2 module is needed (instead of php_embed) - TSRMLS_FETCH() needs to be called at the start of every request - ts_free_thread() should be called at the end of every request But I still would like to get any comment about my patch... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits expecting interfaces implicitly leads to expensive runtime checks
On Sun, Dec 12, 2010 at 7:25 AM, Jonathan Bond-Caron jbo...@openmv.comwrote:
On Sat Dec 11 10:25 AM, Stefan Marr wrote:
http://wiki.php.net/rfc/horizontalreuse#requiring_composing_class_to_impleme
nt_interface
Are there any objections to implementing this?
It's not a bad idea, though I haven't found a strong need for it in the way
I plan to use traits.
Do you intend to use traits as reusable implementations of interfaces? If
not, I could see why this feature isn't of interest to you :)
It also turns a trait into something more complex 'copy paste' code with
requirements/dependencies.
I think copy paste is a good way to conceptualize traits, but feel,
practically, they're a bit more complex than that w/ conflict resolution,
traits composed of traits, and the issue w/ attributes Stefan has brought
up. Essentially, there are already rules being added around the copy
paste concept. Also, this feature is mostly an extension of the abstract
keyword concept in traits, which they already support.
-1 on using 'require' (T_REQUIRE token), an option could be 'within'
trait IteratorUser within Iterator {
function foo() {
$next = $this-next();
...
}
}
class MyIterator implements Iterator {
with IteratorUser;
}
So the 'with/within' tokens would apply to traits.
I feel 'expect', 'need', 'require' etc sound better, matter of opinion
really, but it sounds like from an internals perspective it's preferred to
reuse existing keywords if possible.
Overall I feel -1, more use cases around Trait expresses a requirement for
the composing class would help, it seems like useful theory... not
convinced it's worth the trouble.
If you see the value in the abstract keyword in abstract classes or moreover
interfaces in general, I'd consider the value of this feature equal. Of
course not everyone uses abstract classes or interfaces :D
-nathan
