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.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
