>> Another related topic. We were planning to allow expressions encoded
>> as strings (e.g. "xyz.abc = ..and mnk != %@", you see what I am
>> talking about). I wonder how we can express the case above (and more
>> complex ones with splits) in this format as well? Add an operator for
>> "match all" or something? (SQL has "ALL" operator, maybe use it too?)
>
> Excellent question; I was forgetting about this topic altogether, as we
> never use it in EOF as it was missing a fundamental feature: being able
> to extend the string analyzer, in order to be able to create newly
> coded Expressions within the same procedure.
>
> What I would have like to have in EOF was a way to be able to tell the
> framework that the syntax "xyz.abc = (80, 30, 4)" should have create an
> instance of MatchAllValuesQualifier.
>
> Besides what the final syntax will look like, I will like to sort out a
> way to have a collaborative process (between all defined subclass of
> Expression) to transform strings in Expressions, thus allowing newly
> created Expression subclass to have the option of joining the
> translation process.
>
> No idea on how to implement this, yet, but I will try to think on how
> to include it in the code I am writing.
Handcoding a parser in Java is probably not good anyway. I would suggest
using JavaCC grammar (an analog of UNIX lex/yacc). We are currently using
similar approach when doing plist parsing (see Parser.jj in
wocompat/parser).
Custom extensions can be coded by providing alternative grammar (much
easier than writing a parser from scratch). Parser.jj file compiles to a
Parser.java file, which in turn compiles to Parser.class. A user can do
this with his own grammar file and install his own Parser class by calling
a static method somewhere in expression package.
Andrus
This archive was generated by hypermail 2.0.0 : Tue Oct 21 2003 - 12:38:46 EDT