On 01.11.2015 06:26, Ondrej Pokorny wrote:
+ I was wrong about the need to use "tenumeratornode". Actually you can
use "tcallnode" and get *pd* and *expr* for
*create_enumerator_for_in_loop* from its properties in function
*create_for_in_loop*:
expr:=tcallnode(expr).methodpointer;
pd:=tprocdef(tcallnode(expr).symtableprocentry.ProcdefList[xyz]); //
(you have to find the compatible overload)
(If you don't know what I mean I can send you the code. It's working
like a charm.)
I personally think it's better to use tcallnode than to introduce
another node. I know there is already a parser only node, namely
specializen (added by me), but that node /really/ simplifies things
unlike that enumerator node.
The only thing we need is a new flag/whatever so that
*create_for_in_loop* knows that "tcallnode(expr)" contains an enumerator
function. tnode.flags seems to be full :( Do you have any suggestions?
If we sort this out, 2 more arguments against it are nil :)
I see three possibilities to avoid the addition of a global flag:
- simply always return the enumerator function if no arguments are given
for an indexed array (pro: easy to implement; con: will bite us once we
add another functionality that works on the array property as a whole)
- always return the enumerator, but add checks everywhere except the
for-in parsing against the enumerator (maybe for this case the
enumerator node would be an advantage) (pro: enumerator will only work
in for-in; con: every expression handling code needs to maintain that code)
- extend comp_expr by another boolean parameter (which is set in
for_in_loop_create) and pass that down to factor (even better: convert
the boolean parameters of comp_expr, sub_expr and factor to a set, would
be cleaner anyway, IMHO) (pro: the state is only maintained locally and
new flags can be added easily; con: a greater change in the compiler,
though that would be a onetime thing)
I personally would prefer point three. Maybe I'd even manage to do that
change during this week (I have vacation after all, so I should have
time ^^) and then you can redo your patch based on this.
Regards,
Sven
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
