Thomas Schatzl wrote: > Hello, > > I think I have to make some things more clear why I am in favor of > that "foreach": > > Thomas Schatzl schrieb: > >>>> Features being developed now are: >>>> MI interfaces 90% (MI=multiple inheritance) >>>> Inclasses 15% (embedded classes) >>>> foreach 0% (well, we know you hate it) >>> >>> >>> It's a useless statement if used for arrays, enumerations etc. It >>> blows up the language for no gain. > > > You are right, for arrays, enumerations etc. there is little to no gain. > But I see the application of foreach on these types as added bonus, not > the main thing. > > As far as I understand the proposal the main point for this construct is > the use in iterable container classes (implementing a certain > interface). And there it can show it's advantages (or what I think that > are advantages): > > Instead of a very longish (syntax made up just now): > > var > x : IIterable; > someCollection : TSomeCollection; > elem : TSomeElement; > > [...] > x := (someCollection as IIterable).initIterator(); > while (x.hasNextElement()) do begin > elem := (x.nextElement() as TSomeElement).next(); > > << do something with elem >> > end; > x.doneIterator(); > [...] > > you could write: > > x : TSomeElement; > someCollection : TSomeCollection; > > [...] > foreach elem in someCollection do begin > << do something with elem >> > end; > [...] > > which is imo far easier to read. (Please don't mind the word "foreach", > I think it's only because it's already used in other languages for that > purposes). > > The former is also less error prone in regard to using the iterator for > the appropriate element (think of nested foreach's). It is typesafe too. > It makes it easier to quickly change the actual type of (OO-)container > if needed. > > And if basic Pascal types (arrays, sets, etc.) were allowed to be used > in the same construct, then the programmer won't have to worry about > syntax differences in using these basic types and OO-collections too. > > E.g. > > elem : Integer; > someArray : array[X...Y] of Integer; > > [...] > foreach elem in someArray do begin > << do something with elem, e.g. inc(elem); >> > end; > [...] > > or > > elem : TSomeEnumeration; > someSet : set of TSomeEnumeration; > > [...] > foreach elem in someSet do begin > << do something with elem >> > end; > [...] > > In case of sets this may not only be an abbreviation for the for-loop, > but also element testing: > > for elem := low(someSet) to high(someSet) do begin > if (elem in someSet) then begin > << dosomething >> > end; > end; > > Probably this also gives some additional opportunities for code > optimizations.
Well, I bet people would cry if the iterator works randomly and not element by element :) > > But in the end you're right, it's only an abbreviation for already > existing functionality; I'd consider it useful though. I don't like those iterators anyways, they are too unspecific. What happens if you delete element where the iterator points to? What happens, if you delete an element while iterating? Have a look at the STL, it has imo a much better iterator design. Another problem is probably that people would underestimate the overhead of the foreach statement. I guess you remember the tlist/resourcestring overhead trouble. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
