Bug #55214 [Asn->Tbd]: use of __CLASS__ within trait returns trait name not class name

From: Date: Sun, 31 Jul 2011 18:23:25 +0000
Subject: Bug #55214 [Asn->Tbd]: use of __CLASS__ within trait returns trait name not class name
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-162309@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=55214&edit=1

 ID:                 55214
 Updated by:         gron@php.net
 Reported by:        chris dot rutledge at gmail dot com
 Summary:            use of __CLASS__ within trait returns trait name not
                     class name
-Status:             Assigned
+Status:             To be documented
 Type:               Bug
 Package:            Scripting Engine problem
 Operating System:   Ubuntu
 PHP Version:        5.4.0alpha1
-Assigned To:        gron
+Assigned To:        
 Block user comment: N
 Private report:     N

 New Comment:

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.


Previous Comments:
------------------------------------------------------------------------
[2011-07-31 18:18:56] gron@php.net

Automatic comment from SVN on behalf of gron
Revision: http://svn.php.net/viewvc/?view=revision&revision=313997
Log: Fixed Bug #55214 	use of __CLASS__ within trait returns trait name not class name [TRAITS]
[DOC]

------------------------------------------------------------------------
[2011-07-24 18:31:08] gron@php.net

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"

------------------------------------------------------------------------
[2011-07-24 18:28:16] gron@php.net

The following patch has been added/updated:

Patch Name: __CLASS__-in-traits.002.patch
Revision:   1311532096
URL:        https://bugs.php.net/patch-display.php?bug=55214&patch=__CLASS__-in-traits.002.patch&revision=1311532096

------------------------------------------------------------------------
[2011-07-23 17:53:25] gron@php.net

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

------------------------------------------------------------------------
[2011-07-23 17:45:28] gron@php.net

The following patch has been added/updated:

Patch Name: __CLASS__-in-traits.patch
Revision:   1311443128
URL:        https://bugs.php.net/patch-display.php?bug=55214&patch=__CLASS__-in-traits.patch&revision=1311443128

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    https://bugs.php.net/bug.php?id=55214


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=55214&edit=1


Thread (12 messages)

« previous php.bugs (#162309) next »