Reflection, Traits, Aliasing View as Markdown

Stefan,

I recently tried to finalize reflection support for traits. Given code
like

<?php
trait T1 {
public function t1() {}
public function ta() {}
}

trait T2 {
public function t1() {}
public function tb() {}
}

class C {
use T1, T2 {
T2::t1 insteadof T1;
T1::t1 as tc;
}
}
?>

Now I use reflection on this:

$rc = new ReflectionClass('C');
print_r($rc->getTraitAliases());

Array
(
[tc] => T1::t1
)

So far so nice but I'm missing the information where C::t1() is coming
from. In the reflection code I'm currently iterating over
ce->trait_aliases and can't find where I can get the information from.
Actually I'd be even interested in getting all important methods and
their origin. Stefan, do you know where I can find the information or
would we have to store it additionally?

johannes

There seems to be a bug in traits that if you use any of the GLOBAL vars it
segfaults

e.g.
<?php
trait tester {
function getStuff($a = null) {
if ($a) {
if (isset($_COOKIE[$a])) {
return $_COOKIE[$a];
}
}
return false;
}
}

<?php
include "tester.php";
class beep {
use tester;

function beeper() {
return $this->getStuff("tester");
}
}

that causes a segfault

change the trait to
<?php
trait tester {
function getStuff($a) {
if ($a) {
if (isset($_COOKIE[$a])) {
return $_COOKIE[$a];
}
}
return false;
}
}

and now you get a zend_mm_corrupted,

this is in 5.4.0-beta1 compiled at 23:59 on 7th

Hi Johannes:

2011/7/25 Johannes Schlüter johannes@schlueters.de:

Now I use reflection on this:

$rc = new ReflectionClass('C');
print_r($rc->getTraitAliases());

Array
(
[tc] => T1::t1
)

Great, that is nice.

So far so nice but I'm missing the information where C::t1() is coming
from. In the reflection code I'm currently iterating over
ce->trait_aliases and can't find where I can get the information from.
Actually I'd be even interested in getting all important methods and
their origin. Stefan, do you know where I can find the information or
would we have to store it additionally?
The functions do not store that information, so there are basically
only two approaches, I see:

Either, factoring out the code which is doing the flattening, conflict
resolution, and class composition into something which could be easily
shared by both the reflection and the engine, and then re-doing it on
demand in the reflection,
or we extend zend_function by an origin pointer.

Not sure what the better tradeoff is general memory overhead vs.
cache-able pay-as-you-go overhead.

Is it really worth any overhead here at all? This information is still
there, you just have to work at it a bit. You know which traits are
being used for class C. T1 and T2. You can look at T1 and T2 and see
they both provide t1 methods, but you see from the list of aliases on C
that T1::t1 was aliased to tc, therefore C::t1 must come from T2 since
the trait is used in C and it isn't aliased. I don't think we need
anything else here.

-Rasmus