Hi Joshua,
seams to me the interest in traits decreases rapidly :(
Joshua Thompson schrieb:
trait A1 {
private $a = 'A1';
private function printA() {
echo $this->a;
}
public function callPrintA1() {
$this->printA();
}
}
trait A2 {
private $a = 'A2';
protected function printA() {
echo $this->a;
}
public function callPrintA2() {
$this->printA();
}
}
class A {
include A1 {
public callPrintA1();
}
include A2 {
public printA();
}
public function callPrintA() {
$this->printA();
}
}
$a = new A();
$a->callPrintA1(); // 'A1'
$a->callPrintA2(); // Fatal Error: Undefined method...
$a->callPrintA(); // 'A2'
This is what Marcus aso. has been looking for, yes.
Merging Multiple Methods or Properties
--------------------------------------
Merging is an extension of aliasing. Instead of aliasing properties or
methods to unique names, multiple properties or methods are aliased to
the same name, and an implementation of the method or a value for the
property is placed in the combined class.
I do not understand how this is supposed to work with methods?
Merging properties is fine, but methods?
Implementation Ideas
====================
1) Flatten
2) Don't Flatten
Flatten
-------
The idea here is to place all of the properties and methods into the
class definition at compile time. This makes it possible to run the code
as if traits don't even exist. The benefits of this is that the run-time
internals of PHP should not be affected. The downside is that compiling
becomes more complicated.
To keep methods and properties from colliding, some kind of
alpha-renaming of those that are locally scoped must be made. The most
common suggestion is to append the trait name (including namespace) to
the front of the method or property seperated by the double colon (::).
This should be an acceptable solution to the issue. However, every use
of the method or property within the trait, must be changed to this new
name.
Don't Flatten
-------------
Instead of flattening, the traits could be kept separate from the class.
Instead, during runtime, when a call is made to a trait method or
property, the correct action is decided. This will require changes to
the run-time internals of PHP, but could provide some benefit to opcode
caches, as they could cache the trait once and use it for each of the
classes that include it.
Well, now traits aren't much distinguishable from classes anymore. Here
might be the opportunity to drop it as a separate concept and introduce
it as a private mixin concept with the chance to avoid conflicts and the
explicit need to make methods/properties non-local/private to the mixin.
But, even if this non-breaking traits/mixins are a nice opportunity to
achieve better reuse and avoid conflicts it seams to be more complex.
One point I don't like this much, is the need to name every method I do
like to have in my class accessible explicitly. This is much more to
type it is with my latest proposal.
Hope the other internal folks around keeps on discussing traits or
non-breaking traits. I really would like to see one of the discussed
flavor making it into the language (well, I'm still revering my own
proposal ;) )
Kind Regards
Stefan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
