[fpc-devel] New feature discussion: for-in loop

[Michael Van Canneyt]

On Wed, 21 Oct 2009, Matt Emson wrote:

> Micha Nelissen wrote:
>> Michael Van Canneyt wrote:
>>> Because with something like
>>> 
>>> Type
>>>   MyIterator = Iterator(TSomeResultType,Func1,Func2,Func3);
>> 
>> So the place in this list determines its function?
>
> The syntax is nice and simple, but I would have to agree. Maybe a two step 
> would be better? Like with converting an enum to a set?
>
> type
> MyIterator = Iterator of TSomeResultType;
>
> MyIteratiorDefinition = class(MyIterator) //class might be another keyword
>   iteration Func1; MoveNext;
>   iteration Func1; MovePrior;
>   {etc}
> end;
>
> and then tag methods as so? I think though, that the original  suggestion 
> would work if very well documented or allowing for additional tags somehow?
>
> MyIterator = Iterator(TSomeResultType, Func1::Next, Func2::Prior);

Nono, A::B is very unpascalish. The location uniquely determines whatever
you need to make the iterator work.

Just like in operators:

operator + (A : Real; B TSomeRecord) : Z : TSomeRecord;

A,B, and Z have fixed positions and meanings. Only the names vary.

>
> The list could also then be variable. If it isn't variable with default 
> implementations for missing members, I don't see the reason why the method 
> names can't be fixed - or am I missing something obvious? Having a fixed list 
> may well be confusing should it ever need to be expanded or adapted.

1. The whole point of the exercise is to avoid fixed class or method names.

2. You need only 2 or 3 methods. A for loop in C also has 3 "fields" or
    "statements" or wwhatever, and the location determines univocally
    what it means.

It's pascal. If we really must introduce iterators - I still think they are
unnecessary bloat - Let's at least keep it simple and clean and similar to
existing features.

Michael.