tom_at_work at gmx.at
Thu Apr 7 13:48:28 CEST 2005
Marco van de Voort schrieb:
>>you could write:
>>x : TSomeElement;
>>someCollection : TSomeCollection;
>>foreach elem in someCollection do begin
>> << do something with elem >>
> True, BUT... hmm, I actually have 3 BUTS
It is some sort of syntactic sugar, so all your but's are valid at least
in some way. Nobody ever doubted this.
> BUT 1: some form shorter syntax can be thought up for _each_ _and_
> BUT 2: The whole purpose of iterators is that you can have multiple orders
>on the same object, and get a different iterator to get a different order.
I disagree, the main purpose of iterators is to provide uniform
iteration over containers (e.g. to use the same code to iterate over
That there are different types of iterators (forward, backward, and
random access, readonly, writeable, ...) is definitely a feature of a
specific iterator imo.
If you have to program differently for every container (for i := low(x)
to ..; for i := 0 to count-1 ...; etc. etc.) only makes code harder to
understand and error prone without additional gain.
Additionally if you examine code, _far_ the most applications do simple
forward (and maybe backward) iteration over a collection (also because
there are not that much collections where random access makes sense
So maybe it is feasible to enhance the syntax to the following (BNF this
"foreach" element "in" container ["forwards" | "backwards"] "do"
"foreach" element "in" typed-range-expression "do"
container "'" range-expression.
range-expression ::= first-element-spec ".." last-element-spec.
and first-element and last-element being a specification of those. This
can be for arrays: bottom and last element (greetings from e.g.
VHDL/ADA?, see for more details there), for OO containers a
specification of two iterators indicating position, see STL.
But this may be total overkill for the typical application.
*ducks into cover, awaiting flames* =)
>The syntax does not allow this. Typical ss.
You are right, it _is_ syntactic sugar. Never doubted it. But iterators
may be an important tool in programming which may justify inclusion into
> BUT 3: I myself currently use iterators at work (modeled after decal,
> except without the variant-interface stuff, because of performance) and
> your example looks overly verbose;
> var iter:dlightmapiterator;
> while lightmapiterateover(iter) do
> << do something with getobject(iter)>>
> // no finalisation of iter necessary.
> Is this so bad ? I don't see the problem
I'm not sure that I'm interpreting your code sequence correctly, but I
don't consider this design as very good either (maybe driven by
implementation considerations though) - you lost abstraction over the
container type which forces the programmer to learn the correct commands
for every type of container (which isn't too hard assuming that they are
pretty similar - but there is no real *gain* for doing that. And you
don't lose anything when you do it the other way)
The finalization is a pure design issue, depending on the capabilities
of the container (thread safety, safe for container modification, ...)
which may be needed to properly release used resources. This is an option.
Additionally you lost type safety (e.g. missing the typecast of the
retrieved object =).
Taking all that into account there isn't much difference in typing
between the two proposals, isn't there?
>>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
> IMHO it sucks. Write a code template for your IDE if you really want to
> spare out those 10 key strokes.
More information about the fpc-pascal