Edit report at https://bugs.php.net/bug.php?id=55214&edit=1
ID: 55214
Patch added by: g...@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
Type: Bug
Package: Scripting Engine problem
Operating System: Ubuntu
PHP Version: 5.4.0alpha1
Assigned To: gron
Block user comment: N
Private report: N
New Comment:
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
Previous Comments:
------------------------------------------------------------------------
[2011-07-23 17:53:25] g...@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] g...@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
------------------------------------------------------------------------
[2011-07-23 14:17:24] fel...@php.net
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.
------------------------------------------------------------------------
[2011-07-22 04:56:04] g...@php.net
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
------------------------------------------------------------------------
[2011-07-15 06:44:47] chris dot rutledge at gmail dot com
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?
------------------------------------------------------------------------
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
