dmitry boyarintsev wrote 9 lines
Hello, Michael Van Canneyt,
Sorry, I can't write to the resolved issue (without re-opening) it.
> - better class tree (split out binary/unary/primitive operators in subclasses)
> These may break backwards compatiblity; if you prefer to do them yourself, I can say what I have in mind.
That's how it was originally written. However, I personally prefer to
keep less subclasses.
I prefer more, with less fields, it saves memory on big expressions :-)
I would like to hear your ideas.
Well, at least I would have expected 4 subclasses: TPasExpr
+-- TUnaryExpr (field operand)
+-- TBinaryExpr (fields left, right)
+-- TPrimitiveExpr (field 'value')
+-- TFunctionCallExpr (fields value/params)
I must say that I am not familiar with the parsing style you used. I wrote 2 expression parsers meanwhile, and both used a different style. (see fcl-base/fpexprpars.pp; the other one is in fcl-js. A third will follow in the sql parser I'm about to commit)
Show quoted text 7 lines
thanks,
dmitry
P.S.. the expression parser still doesn't resolve ranges (i.e. in
sets), neither simple nor complex, like:
Char(6) in [Char(sizeof(Integer))..Char(SizeOf(int64))]
That should be relatively easy to add, no ?
Michael.
