At 01:44 10/7/2001, Sascha Schumann wrote:
> > Then it is incompatible with the parser.  Unless you mean slightly
> > different tokens in HTML blocks, which is obviously a negligible
> > performance-related implementation detail.
>     Nah, there are a couple of other things which it does
>     differently where the parser apparently accepts multiple
>     representations of a certain item.

Ok, so a few more negligible things.  It doesn't really matter, its output 
is not different from say, a slightly different version of the flex scanner.

>     Beside from that, I still maintain the point that the current
>     Zend Code is too directly tied to the scanner implementation
>     and that it makes sense to provide a single constant API to
>     the lexer.  It certainly would facilitate further work in
>     this area.

I disagree.  I do believe you wouldn't have even thought about this 
solution if it wasn't for the license issue.  Having an extra layer of 
abstraction in this case is bloat and some overhead.  We can improve the 
scanner and perform 'further work' without abstracting anything, just like 
we do everywhere else.


PHP Development Mailing List <>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to