> > How about: > > > > DATE = nnnn-nn-nn > > NUMBER = n* > > RANGE = [ DATE : DATE ] | [ NUMBER : NUMBER ] > > > > An alternate, less parse-oriented approach would be this: > > RANGE = [ GOOP : GOOP ] > > where > > GOOP = any string of letters/numbers not containing : or ]. > > I'd go for the first one as it's more explicit. However, perhaps the > second approach is more extensible?
When I first did the query parser, I defined terms by inclusion (stating valid characters) instead of exclusion (excluding non-term characters.) Turns out I missed quite a few in the first go around, which taught me the lesson (again) that sometimes trying to be too specific is a rats nest. What about dates like 02-Mai-2002 (not a typo, french for May)? Letting DateFormat figure it out has some merit. > DateField(Date) and NumberField(int) sounds right, but wouldn't Field > class make more sense? I had in mind static methods of Field, just like Field.Text -- Field.Date, Field.Number. Sorry if that wasn't clear. This seems an easy addition. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
