<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 01.11.2015 16:38, Jonas Maebe wrote:<br>
</div>
<blockquote cite="mid:563631EA.1050809@elis.ugent.be" type="cite">The
basic issue is that you need extra context for supporting this
extension. Normally, an enumerator is searched based on the class
type. In your case, it's searched either based on the class type,
or if the class is returned from a property with an "enumerator"
specifier, based on that enumerator declaration.
<br>
<br>
Whether you do it via a temporary node, a global variable and/or
node flags, does not change that. Extra context is always bad both
for the compiler implementation/maintenance and for code
readability/predictability by humans.
<br>
</blockquote>
<br>
Yes, the context is new. Yes, every new feature adds maintenance
efforts. But this is not an argument...<br>
Speaking from my point of view, I do expect to be able to enumerate
over array properties just as I enumerate over array variables. It
feels very natural. <br>
<br>
I don't understand the design decisions you talk about below:<br>
<br>
<blockquote cite="mid:563631EA.1050809@elis.ugent.be" type="cite">This
leads to more design design decisions:
<br>
1) do you a) forbid an enumerator specification if the class
already has an enumerator, b) hide the existing enumerator, or c)
allow enumerating both via the property and the original class
enumerator? If you all both, how do you differentiate? If b),
first assigning the property to a variable and iterating over that
will have a different result than directly iterating over the
property, which is bad for understandability and code
predictability. If c), how do you specify it. If a), that break
orthogonality (and I'm sure some people will argue that iterating
over a particular property may have to be done differently than
over that class' contents in the general case)
<br>
</blockquote>
<br>
The extension is completely orthogonal - there is no redundancy in
the code. Again if I take the project1.lpr from the issue report:<br>
<br>
<b> for s in StringArray do</b><b><br>
</b><b> Writeln(s);</b><b><br>
</b><br>
will never compile without the extension. The StringArray property
cannot introduce/return an enumerator. In absolutely no case.<br>
<br>
<blockquote cite="mid:563631EA.1050809@elis.ugent.be" type="cite">2)
do you expose the "hidden/parent" enumerator of the class itself
to the overriding enumerator in a property and if so, how? Maybe
even iterating both at the same time via some kind of inheritance
mechanism?<br>
</blockquote>
<br>
If you are talking about something like this:<br>
<br>
TTest = class<br>
//...<br>
public<br>
function <b>GetEnumerator</b>: TTestObjectEnumerator;<br>
property StringArray[Index: Integer]: string read GetString
enumerator <b>GetEnumerator</b>;<br>
end;<br>
<br>
then this is again absolutely no problem. The code:<br>
<br>
<b> for s in Self do</b><b><br>
</b><b> Writeln(s);</b><b><br>
</b><br>
and<br>
<br>
<b> for s in Self.StringArray do</b><b><br>
</b><b> Writeln(s);</b><b><br>
</b><br>
will do the same thing. Again, this is very natural.<br>
<br>
<blockquote cite="mid:563631EA.1050809@elis.ugent.be" type="cite">
There are undoubtedly more.
<br>
</blockquote>
<br>
I don't think so. Please be specific. "undoubtedly more" doesn't
sound very scientific :)<br>
<br>
Ondrej<br>
<br>
</body>
</html>