On Wed, 2011-03-23 at 13:49 -0700, Cédric Beust ♔ wrote:
[ . . . ]
>
> First of all, before the enhanced for loop came out, Java was using
> iterators pretty much everywhere in collection loops:
>
> for (Iterator it = collection.iterator(); it.hasNext(); ) {
> Object o = it.next();
> }
My point was that the interface of Iterator, and Enumerator before it,
was the wrong choice. This implements forward iterator which is very
restrictive -- especially if what you really want is bidirectional
iterator or random access iterator.
> This followed the techniques made popular by the STL, but it was seen
> as not just a lot of boiler plate but also exposing users to needless
> implementation details: if all you want is enumerating the objects in
> a collection, why should you even care about the concept of iterators?
No, Collections did not follow STL. Iterator (and indeed Enumerator
before it) didn't learn the lessons of STL at all. The STL has a far
richer view of iterator than Collections offers. It was JGL that tried
to realize this richness, as did my own ADS -- a library created to
teach all this stuff to students -- Collections ignored all the
knowledge of how to use iterators in C++ that STL had built up.
You cannot build up the rich generic programming style that the C++
iterator infrastructure allows based only on forward iterator. This is
why JGL (and ADS) were created. However, Collections was the standard,
so JGL died. The story of ADS is for another place.
>
> Thus, the enhanced for loop was born:
>
>
> for (Object o : collection) {
> ...
> }
Well this (or at least something like it) should have been in Java in
the first place. This idiom was already in many languages in the early
1990s, but the Oak/Java folk chose to stick to the very low-level view
of iteration. They should perhaps have talked more to the Self folk
who apparently were in the next door offices.
>
> No more iterators, much easier to read, and the only objects involved
> in this construct are the ones you care about: the collection and the
> objects it contains.
If all you want is a forward iterator. In the cases where you want
that, foreach is ideal -- witness that most languages have this
construct these days.
>
>
> Joshua Bloch has at least acknowledged
> that the Java Collections framework took the wrong
> architectural
> decision;
>
>
> Uh, citation? We came up with the enhanced for loop precisely to hide
> iterators, so I still claim that the enhanced for loop is a big
> improvement over what we had before.
I am not disagreeing with this for the one use case of forward iteration
over the whole container -- which happens to be a majority use case and
so crucially important. However, it is not 100% of the use cases, so
other iteration structures are needed. C++, D, etc. provide that richer
iteration framework, Java does not. java.util.Iterator is and always
will be a forward iterator that does not provide a rich enough iteration
structure to provide the generic programming as seen in C++, D, etc.
>
> Or are you referring to something else?
Personal communication, JavaOne 2004.
I finally met up with Neal Gafter, with whom I had been having various
email exchanges over the previous 8 years, on the Sun stand and Joshua
Block was there as well. The conversation naturally turned to
Collections and thence to the iterator structures. Paraphrased
Joshua's comment was "I am happy with the way things are going forward,
but if I were to do it again, I would probably do it differently, more
like STL."
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
