<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">First of all thanks Sven and Michael
for the positive feedback! I was already worried that I was
completely misunderstood with the property array enumerator
extension.<br>
<br>
About your 3 points, Sven:<br>
<br>
On 02.11.2015 20:24, Sven Barth wrote:<br>
</div>
<blockquote cite="mid:5637B863.6040806@googlemail.com" type="cite">
<blockquote type="cite" style="color: #000000;">The only thing we
need is a new flag/whatever so that
<br>
<b class="moz-txt-star"><span class="moz-txt-tag">*</span>create_for_in_loop<span
class="moz-txt-tag">*</span></b> knows that
"tcallnode(expr)" contains an enumerator
<br>
function. tnode.flags seems to be full :( Do you have any
suggestions?
<br>
If we sort this out, 2 more arguments against it are nil :)
<br>
</blockquote>
<br>
I see three possibilities to avoid the addition of a global flag:
<br>
- 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)
<br>
</blockquote>
<br>
Yes, this is not very clean. Furthermore such code would compile as
well:<br>
<br>
x := MyObj.MyArrayProperty;<br>
<br>
(x would get the enumerator function, which is wrong.)<br>
<br>
<blockquote cite="mid:5637B863.6040806@googlemail.com" type="cite">-
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)
<br>
</blockquote>
<br>
Looks unnecessarily complicated.<br>
<br>
<blockquote cite="mid:5637B863.6040806@googlemail.com" type="cite">-
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)</blockquote>
<br>
Looks unnecessarily complicated for me as well.<br>
<br>
---<br>
<br>
From my POV, having thought about the problem for some days already,
the use of tenumeratornode is the simplest and clearest way to
achieve the goal. The property array enumerator use in for-in is a
"single case" only. So the use of a single-purpose node is clear as
well - everybody understands on the first sight what is going on.<br>
<br>
It is way more dangerous and unclear if you use some flags or
parameters that change the tcallnode handling. If you use
tenumeratornode you clearly see in what code parts it is used and
how. If you use tcallnode + some flag/parameter it will be devil.
For such reasons there was OOP invented, so we should take advantage
of it.<br>
<br>
If you don't want to include the "enumeratorn" into tnodetype and
the "is" operator from my first proposal is too slow, you can also
directly type check for tenumeratornode in create_for_in_loop (in
the case you don't allow tenumeratornode ancestors, of course):<br>
<br>
if <b>expr.ClassType = tenumeratornode</b> then<br>
begin<br>
// the expr is a property enumerator, use it
directly<br>
pd:=tenumeratornode(expr).enumproc;<br>
expr:=tenumeratornode(expr).enumowner;<br>
end<br>
<br>
Ondrej<br>
</body>
</html>