Bug #65419 [Ver]: Inside trait, self::class != __CLASS__

2013-09-12 Thread ralphschindler 
Edit report at https://bugs.php.net/bug.php?id=65419edit=1

 ID: 65419
 Updated by: ralphschind...@php.net
 Reported by:nicolas dot grekas+php at gmail dot com
 Summary:Inside trait, self::class != __CLASS__
 Status: Verified
 Type:   Bug
 Package:Scripting Engine problem
 PHP Version:5.5.1
-Assigned To:
+Assigned To:ralphschindler
 Block user comment: N
 Private report: N

 New Comment:

Ill work up a patch that will demonstrate ::class resolving in traits similar 
to how __CLASS__ works in traits.

This seems to be the consensus (correct me if I am wrong), and consistent with 
__CLASS__ (to some degree) in traits.


Previous Comments:

[2013-08-14 10:10:48] nicolas dot grekas+php at gmail dot com

Why remove ::class support inside traits? It mostly works today, and it is as 
usefull there than inside classes or anywhere else, am I wrong?

Would it be possible to replace self::class occurences by __CLASS__ at compile 
time so that the code path for __CLASS__ is also used here?


[2013-08-11 15:31:06] larue...@php.net

I prefer to trigger a COMPILE ERROR prevent from using ::class in a traits


[2013-08-09 07:57:41] g...@php.net

Yes, that looks wrong. It should indeed behave as __CLASS__.


[2013-08-09 07:55:23] nicolas dot grekas+php at gmail dot com

I totally agree with you.

This reminds me the discussion that happened in https://bugs.php.net/55214 and 
that led to this special handling for __CLASS__.

I think that the very same arguments apply here also.

Concerning parent and static, they are free from this problem because they are 
resolved at run-time (tested, it works).


[2013-08-08 18:33:55] requi...@php.net

The RFC was created a few weeks after 5.4.0 was released and does not specify 
how self::class would work for traits. I would take that to mean the writer did 
not consider how it would 
work for traits, rather than that traits should inherit the behavior for 
classes.

So either this is a doc bug and the ::class doc should state that it resolves 
to the trait itself when used for traits (as a ::trait syntax would be 
weird), or self::class is fixed so 
be identical to __CLASS__. Presumably parent::class and static::class would 
receive similar changes.

Note for the latter: in zend_language_scanner, __CLASS__ has special handling 
when used inside traits. I imagine similar logic - creating a special 
__CLASS__ constant - would be used in 
zend_do_resolve_class_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=65419


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

Bug #65419 [Ver]: Inside trait, self::class != __CLASS__

2013-08-11 Thread laruence 
Edit report at https://bugs.php.net/bug.php?id=65419edit=1

 ID: 65419
 Updated by: larue...@php.net
 Reported by:nicolas dot grekas+php at gmail dot com
 Summary:Inside trait, self::class != __CLASS__
 Status: Verified
 Type:   Bug
 Package:Scripting Engine problem
 PHP Version:5.5.1
 Block user comment: N
 Private report: N

 New Comment:

I prefer to trigger a COMPILE ERROR prevent from using ::class in a traits


Previous Comments:

[2013-08-09 07:57:41] g...@php.net

Yes, that looks wrong. It should indeed behave as __CLASS__.


[2013-08-09 07:55:23] nicolas dot grekas+php at gmail dot com

I totally agree with you.

This reminds me the discussion that happened in https://bugs.php.net/55214 and 
that led to this special handling for __CLASS__.

I think that the very same arguments apply here also.

Concerning parent and static, they are free from this problem because they are 
resolved at run-time (tested, it works).


[2013-08-08 18:33:55] requi...@php.net

The RFC was created a few weeks after 5.4.0 was released and does not specify 
how self::class would work for traits. I would take that to mean the writer did 
not consider how it would 
work for traits, rather than that traits should inherit the behavior for 
classes.

So either this is a doc bug and the ::class doc should state that it resolves 
to the trait itself when used for traits (as a ::trait syntax would be 
weird), or self::class is fixed so 
be identical to __CLASS__. Presumably parent::class and static::class would 
receive similar changes.

Note for the latter: in zend_language_scanner, __CLASS__ has special handling 
when used inside traits. I imagine similar logic - creating a special 
__CLASS__ constant - would be used in 
zend_do_resolve_class_name().


[2013-08-08 08:44:05] nicolas dot grekas+php at gmail dot com

Description:

The RFC for ::class name resolution as scalar say that self::class resolves the 
same as __CLASS__:

https://wiki.php.net/rfc/class_name_scalars#considerations

But this is not true when using traits.

Test script:
---
?php

trait abc
{
  static function def()
  {
echo self::class, \n;
echo __CLASS__, \n;
}

class ghi
{
  use abc;
}

ghi::def();

Expected result:

ghi
ghi

Actual result:
--
abc
ghi






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