Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45420
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain stefan-marr.de from 85.88.12.247 cause and error)
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
Mime-Version: 1.0 (Apple Message framework v1074)
In-Reply-To: <E997C4AB-143B-477B-8EFD-E28B57FB1EB0@stefan-marr.de>
Date: Thu, 27 Aug 2009 13:01:17 +0200
Content-Transfer-Encoding: 7bit
Message-ID: <C661F795-9241-4D93-BE2A-0F3174B8F5BA@stefan-marr.de>
References: <E997C4AB-143B-477B-8EFD-E28B57FB1EB0@stefan-marr.de>
To: internals@lists.php.net
Subject: Re: [PHP-DEV] How to hand along data in PHP's parser?
From: php@stefan-marr.de (Stefan Marr)

Hi internals:

I still have not solved this problem.
An alternative solution would be to introduce additional state into  
the compiler globals. Are there any standards or common practices for  
such things?

Thanks and best regards
Stefan

On 23 Aug 2009, at 22:47, Stefan Marr wrote:

> Hi internals:
>
> Currently, I try to port my Traits patch to the latest version of  
> trunk.
> Thought about giving you people the chance to play with it again.
> Unfortunately, I have some trouble with the parser.
> Think, there must have changed quite something in its internal  
> working.
>
> The last time I touched it, I had no problems handing around  
> pointers in $$.u.var,
> but nowadays, it looks like it is overwritten before it can be used  
> by the other grammar rule.
>
> The original idea was to construct as many data during the  
> compilation phase to avoid introducing a whole of a lot new opcodes.
> But, I am grateful for all suggestion about alternative  
> implementation strategies.
>
> For the problem at hand, here some code:
>
> <code>
> trait_adaptation_statement:
> /* here I emit a opcode to add a new alias or precedence rule to a  
> class */
>  trait_precedence ';'	{ zend_add_trait_precedence(&$1 TSRMLS_CC); }
> | trait_alias ';'	{ zend_add_trait_alias(&$1 TSRMLS_CC); }
> ;
>
> trait_precedence:
> /* This rule constructs a struct with the necessary data and should  
> return
>   a pointer to it in $$.u.var */
>  trait_method_reference_fully_qualified T_INSTEAD  
> trait_reference_list	
>    { zend_prepare_trait_precedence(&$$, &$1, &$3 TSRMLS_CC); }
> ;
>
> trait_reference_list:
>  fully_qualified_class_name
>    { zend_init_list(&$$.u.var, Z_STRVAL($1.u.constant) TSRMLS_CC); }
> |  trait_reference_list ',' fully_qualified_class_name
>    { zend_add_to_list(&$1.u.var, Z_STRVAL($3.u.constant) TSRMLS_CC);  
> $$ = $1; }
> ;
>
> trait_method_reference_fully_qualified:
>  fully_qualified_class_name T_PAAMAYIM_NEKUDOTAYIM T_STRING
>  { zend_prepare_reference(&$$, &$1, &$3 TSRMLS_CC); }
> ;
> </code>
>
> The code is basically unchanged from http://www.stefan-marr.de/traits/traits.patch
>
>
> My problem starts already with trait_method_reference_fully_qualified.
> I am not able to get the struct which I assigned to $$.u.var in   
> trait_precedence.
> From what XCode tells me, the memory location of $$ gets overwritten  
> before.
> Think, it is on the stack somewhere and does not survive long enough  
> to be
> available in trait_precedence.
>
>
> Any thoughts on that?
>
> Many thanks and best regards
> Stefan