Hi Stas:
On 13 Jan 2012, at 19:53, Stas Malyshev wrote:
> I've done some checks and discovered __CLASS__ behaves somewhat strangely
> with traits. COnsider this code:
>
> <?
> trait foo {
> public $bar = __CLASS__;
> function bar() { var_dump($this->bar); }
> }
>
> class foofoo {
> use foo;
> }
>
> class foofoo2 {
> use foo;
> }
>
> $a = new foofoo();
> $a->bar();
> $a = new foofoo2();
> $a->bar();
> echo "OK!";
>
> Before the patch, it prints $this->bar as NULL.
Yes looks like another hole in the things I covered :-/
The attached test defines the intended behavior. Like you said, __CLASS__ is
expected to give the using class. My testing covered so far only the handling
of __CLASS__ in methods.
The fatal you see in the patched version is coming from Dmitry's new opcode,
which is probably doing already almost the right thing.
Will try to look into it tomorrow.
Until then, the stacktrace below gives some details on what is going on.
Best regards
Stefan
Breakpoint 3, zend_do_early_binding () at zend_compile.c:4602
4602 zend_error(E_COMPILE_ERROR, "Invalid binding
type");
(gdb) p opline->opcode
$1 = 159 '?' // == ZEND_CLASS_NAME
(gdb) bt
#0 zend_do_early_binding () at zend_compile.c:4602
#1 0x000000010025030e in zendparse () at zend_language_parser.c:230
#2 0x000000010025a4cc in compile_file (file_handle=0x7fff5fbff200, type=8) at
zend_language_scanner.l:579
#3 0x00000001002c5ab6 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at zend.c:1264
#4 0x0000000100208683 in php_execute_script (primary_file=0x7fff5fbff200) at
main.c:2476
#5 0x000000010049bb83 in do_cli (argc=2, argv=0x7fff5fbff4b0) at php_cli.c:983
#6 0x000000010049d8c5 in main (argc=2, argv=0x7fff5fbff4b0) at php_cli.c:1356
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
