Re: [cilib-devel] [PATCH 0/3] Replacement of Domain string parser.

[Gary P. <gpa...@gm...>]

For now, I don't think so.

The parser is quite an important internal component. The generation side is 
only required for development. Once the classes are packaged it will remain to 
seem like "any other POJO" in the project.

If the parser gets more complex and starts doing oither things, then we could 
consider it. As it's just focused on the domain strings, it's actually rather 
small.

On Thursday 11 June 2009 08:28:16 Theuns Cloete wrote:
> Hey Gary,
>
> Would it make sense to split the parser into a separate maven module?
> This way the parser code only has to be generated once, and the JAR
> file can just be included in the classpath.
>
> Regards
> --
> Theuns
>
> On Wed, Jun 10, 2009 at 12:51 PM, Gary Pampara<gpa...@gm...> wrote:
> > The need to have a decent parser for the domain strings is something
> > that has been on the cards for a very long time. The main problem with
> > the current implementation is that it is very non-expressive.
> >
> > Illegal domains such as:
> >  - R(8, 9)^-1
> >  - R^0
> >  - Any other strange combination
> >
> > were allowed in the previous parser.
> >
> > These patches propose a new generated parser based on a provided grammar
> > file.
> >
> > JJTree and JavaCC were used to achieve the parser.
> >
> > Gary Pampara (3):
> >  Semi-complete parser definition.
> >  Deprecation of parser for generated parser.
> >  Prevent invalid values / options in domain strings.
>
> ---------------------------------------------------------------------------
>--- Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> cilib-devel mailing list
> cil...@li...
> https://lists.sourceforge.net/lists/listinfo/cilib-devel