Re: [Fwd: Re: org.apache.cocoon.components.language.programming.java package]

[Mircea Toma <mi...@home.com>]

Hi Paul,

> What we wanted to do was compile 'SELECT * FROM WHERE ( ( ( X = 1 AND B
> =2 ) OR ( C LIKE "Fred%") ) AND D <> "Green" )' into.....
>
>   class Select1234 extends BaseSelect {
>      boolean rowMatches(Row row) {
>         (
>           (
>             (
>               row.getValue("X") == 1
>               &
>               row.getValue("B") == 2
>             )
>             OR
>             (
>               row.getValue("C").startsWith("Fred")
>             )
>           )
>           & !row.getValue("D").equals("Green")
>         }
>      }
>   }
>
> on the server side.  And for all selects not just prepared statements.
>  It would be an assembly choice (to use that parser).

Lately I have had the same issues with interpreting/compiling a certain 
language ("Little Language"). Actually the principles of interpreting or 
compiling are similar. I wanted and I still do to create a Shell that will 
allow components to be assembled together. This would be really cool, for 
example manage Phoenix remotely if the Shell will be connected to a telnet 
server.
There are out there a few interesting university projects related to a OO 
interpreting mechanism approach. The ideas are great, the problem is that the 
API-s are not clean and clear at all.
What I wanted to do is to create a few component interfaces like Lexer, 
Parser .... that can be used for any language, only the implementation will 
define the type of language ... maybe have configurable interpreting 
components too.
The problem is I lack the theoretical knowledge for now. But I think this 
approach will be beneficial for having a common API for any "Little Language" 
implementation.

Here are the links to those projects:

http://luna2.informatik.uni-osnabrueck.de/bernd/lolo/
http://luna2.informatik.uni-osnabrueck.de/bernd/oops/

... this one is great but the implementation is not very clean:
http://www.csupomona.edu/~carich/gi/

> > I don't know if it is replaced by another class/entry point, I just know
> > that when I use JDK 1.4 I get a deprecation warnings when compiling the
> > classes.
>
> I guess the Jasper team will work it out.
>
> main(..) is the anti-pattern for IoC.  Roll on an Apache beanlike
> compiler.  Maybe son of BCEL.
>
> > Invoking compilers dynamically has always been a bit of a hack, because

I agree with Berin here, if you want prepared statements maybe a better way 
is to store the Parse Tree and execute it when required.

I know that you put a lot of work in Avalon DB but this was a good time to 
bring forth some of my ideas, hoping to have some sort of concept merger 
under Avalon umbrella.

Mircea





--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>