On Tue, 13 Jul 2010, dmitry boyarintsev wrote:
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)
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.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
