This is the expected behavior. It just need be documented.

It may be expected from the point of view of those developing the 5.4 branch, but 
logically this approach seems flawed.

As one big advantage of traits seems to be as a replacement for copy-and-pasting 
code, maybe consider making __CLASS__ have the value of the class that called the 
trait and a new magic constant __TRAIT__ with the trait name?

Felipe: I tend to disagree, too.

I do not think this is expected behavior.
Will have a look at this, and another bug reported on the QA mailing list hopefully at the weekend.

Best regards
Stefan

It's simple to add the __TRAIT__ one, just like __CLASS__ does.

But making a more magic __CLASS__ to reflect the class that called is too much magic, hacky. Whereas we are currently doing the __CLASS__ substitution on compile-time.

I attached a patch of how a fix could be done.

I have to admit that it is hacky, but I think this is the expected behavior with respect to the metaphor of compiler assisted copy'n'past.

However, the patch is problematic, since it introduces a new memory leak.
And I do not have a good strategy yet to fix it.

Not sure how another patch could work, but the general idea is that __CLASS__ is not actually defined inside a trait (BTW: we should add __TRAIT__, too, yes).
Thus, it resolves to a IS_NULL value.
And as it happens to be, IS_NULL makes all is data members invalid, and I use that to indicate that it isn't actually a NULL value but that I want to fix it up with the class name when the method is actually flattened/copied into the class.

The problem with the memory leak comes from the fact that copying the method is not actually done deeply but shallow. And, I do not know how to free only my fixed up names/ZVALs :-/.

Ok, updated the patch and would like to ask for a review.
This is still hacky, but now I use the literals of a function to be able to clean up the zval for the __CLASS__ name. Thus, the memory leak should be fixed.

Think we will still need a __TRAIT__ to mirror __CLASS__ and to get the trait name itself when that is required.

The test case is missing in the patch:

--TEST--
Bug #55214 (Use of __CLASS__ within trait returns trait name not class name)
--FILE--
<?php

trait ATrait {
  public static function get_class_name() {
    return __CLASS__;
  }
  
  public function get_class_name_obj() {
    return __CLASS__;
  }
}


class SomeClass {
   use ATrait;
}

$r = SomeClass::get_class_name();
var_dump($r);

$o = new SomeClass();
$r = $o->get_class_name_obj();
var_dump($r);

?>
--EXPECT--
string(9) "SomeClass"
string(9) "SomeClass"

Fixed in SVN per http://svn.php.net/viewvc?view=revision&revision=313997

Needs documentation: __CLASS__ gives now the class name in which the trait is eventually used.

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.