[fpc-devel] Debug compiler
lazarus at kluug.net
Sun Nov 1 20:27:32 CET 2015
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
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**
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
function *GetEnumerator*: TTestObjectEnumerator;
property StringArray[Index: Integer]: string read GetString
then this is again absolutely no problem. The code:
* for s in Self do**
* for s in Self.StringArray do**
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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fpc-devel