Jody, thanks for your considerations. I am going to have a look in SQLBuilder.
I am agree with "Parser" name. Seeing filter, in the general context, as subproduct (like data transfer object or object value) to transfer a predicate concept inter tiers, parser name say that the process does not finish, then Parser looks right. About the second point, actually, I am not very convinced. I see filter package as implementation of standard, it encapsulates filters and its components and we can extend standard components with functions and identifier, I am agree, so I understand the original idea is to provide a computational model for "predicates" then the extensions should be functions that can be considered as predicate (return true o false) or other that can be used in expression (components of filters). This is the reason why I think cql parser is not a component of filter package, it is not a filter and is not component of filters. I expect, don' t disturb your weekend :-P. Best regard On Friday 24 November 2006 18:45, Jody Garnett wrote: > What a great email - I really need to make an article on expressing > GeoSpatial stuff in computer science terms .... fun! > > Victor Mauricio Pazos wrote: > > Hi, Gabriel talked me that is possible restructure the toolkit in near > > feature, I have some suggestion for CQL parser. > > > > 1)Name change: Parser is only a component of Compiler ( lex, parser, > > optimization, code generation) We need produce an object and parsing > > process is only part of process, perhaps is better change the module name > > from CQL Parser to CQL Compiler. > > > > The full game is: > (characters)->Lexer -> (tokens)-> Parser -> (Abstract Symbol Tree) -> > Compiler > > We are interested in the Abstract Symbol Tree result; that is the Filter > constructs form a tree. > > So Parser is good. > > > 2)Move CQL from Filter: now we have one implementation with semantic > > actions to generate a Filter. But, this module can be composite changing > > the last step (code generation) to produce others product like SQL, HQL, > > XML, etc. > > That is what we have done throughout the library: > - (Abstract Symbol Tree) -> Compiler -> Result > - Filter --> SQLEncoder -> SQL > > And because this is the real world we have a different SQLEncoder for > each Database. > > We also "run" the Filters directly - they are their own result that can > be used to work on > real in memory Features, Pojos, Metadata. > > > Then Filter product is only an accident and the criteria to maintain cql > > in filter package should be revised. In filter we have a hierarchy of > > filters an its components, We can ask: "is CQL a filter or component of > > filter?". I think, No. > > The Filter product is a specific product (a standard); I suspect if we > were using Antlr that a Filter implementation > could of been constructed directly as part of the Parser step... at the > very least a AST wrapper could be used. > > Also note that the Filter product is not open ended (we cannot add more > nodes and abilities to this syntax); there > are two "open doors" - one to add functions; and another to add > Identifiers. > > > I expect to have done a bit contribution to design debate. > > Regard > > > > Thanks for your comments! I would love to have your impressions on > SQLBuilder; currently they seem > hard to maintain. Perhaps with your insights into them playing the roll > of compiler you could suggest a way > to make them easier to produce and maintain. > > Jody -- Mauricio Pazos Director Axios Engineering www.axios.es e-mail: [EMAIL PROTECTED] tel-:+34 94 441 63 84 fax: +34-94 441 64 90 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
