[fpc-devel] Debug compiler

[Ondrej Pokorny]

On 01.11.2015 16:38, Jonas Maebe wrote:
> 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.
>
> 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.

Yes, the context is new. Yes, every new feature adds maintenance 
efforts. But this is not an argument...
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.

I don't understand the design decisions you talk about below:

> This leads to more design design decisions:
> 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)

The extension is completely orthogonal - there is no redundancy in the 
code. Again if I take the project1.lpr from the issue report:

*  for s in StringArray do**
**    Writeln(s);**
*
will never compile without the extension. The StringArray property 
cannot introduce/return an enumerator. In absolutely no case.

> 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?

If you are talking about something like this:

   TTest = class
   //...
   public
     function *GetEnumerator*: TTestObjectEnumerator;
     property StringArray[Index: Integer]: string read GetString 
enumerator *GetEnumerator*;
   end;

then this is again absolutely no problem. The code:

*  for s in Self do**
**    Writeln(s);**
*
and

*  for s in Self.StringArray do**
**    Writeln(s);**
*
will do the same thing. Again, this is very natural.

> There are undoubtedly more.

I don't think so. Please be specific. "undoubtedly more" doesn't sound 
very scientific :)

Ondrej

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20151101/211b38d3/attachment.html>