RE: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_2) / zend_compile.c
| From: | Andi Gutmans | Date: | Tue, 19 Dec 2006 05:53:06 +0000 |
| Subject: | RE: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_2) / zend_compile.c | ||
| References: | 1 | Groups: | php.zend-engine.cvs |
| Request: | Send a blank email to php-zend-engine-cvs+get-5482@lists.php.net to get a copy of this message | ||
OK cool. No time pressure I think. Whenever you have time.
Andi
> -----Original Message-----
> From: Sara Golemon [mailto:pollita@php.net]
> Sent: Monday, December 18, 2006 9:45 PM
> To: andi@zend.com
> Cc: zend-engine-cvs@lists.php.net
> Subject: Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_2) /
> zend_compile.c
>
> "(2+2) instanceof foo" winds up getting handled in the
> runtime so it "fails right" (Is that a proper expression?)...
>
> I agree with the consistency argument though. Unless you or
> Stas or someone does it first, I'll move the fix over to the
> parser tomorrow.
>
> -Sara
>
> > It's probably more consistent. Very few places check outside the
> > parser and it's usually in cases which are just hard to
> implement in the rules.
> > I haven't tested but I could guess this test doesn't do well with
> > something like (2+2) instanceof foo (not IS_CONST).
> >
> > Andi
> >
> >> -----Original Message-----
> >> From: Sara Golemon [mailto:pollita@php.net]
> >> Sent: Monday, December 18, 2006 9:35 PM
> >> To: andi@zend.com
> >> Cc: zend-engine-cvs@lists.php.net
> >> Subject: Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_2) /
> >> zend_compile.c
> >>
> >> The primary reason I went this route rather than handling
> it in the
> >> parser (I did consider it), was so that a clearer error
> message could
> >> be given than "Unexpected T_STRING". If you'd rather, I'd
> be happy
> >> to move this fix over there...
> >>
> >> -Sara
> >>
> >>> Not sure this is the right fix. It probably makes more
> sense to fix
> >>> the parser itself and use r_variable instead of expr for
> >> the instanceof rule.
> >>> Did you try and have problems doing so? I just took a quick
> >> look so it
> >>> might be a bit more involved than that.
> >>>
>