Re: Problem with Booch iterators

[Simon Wright <simon@pushface.org>]

mheaney@on2.com (Matthew Heaney) writes:

> Simon Wright <simon@pushface.org> wrote in message news:<x7visz0ps4z.fsf@smaug.pushface.org>...
> > mheaney@on2.com (Matthew Heaney) writes:

> > > The BC iterator factory functions return Iterator'Class, which is
> > > indefinite.  You cannot use T'Class as a record component.
> > 
> > But then, given a non-STL mindset, why would you want to? 
> 
> First of all, it is incorrect to associate "definite iterator
> subtype" with "STL."  The issue of definite vs. indefinite subtypes
> has nothing to do with STL vs. non-STL.

Definite vs indefinite ITERATOR subtypes has quite a lot to do with a
Booch view of iteration (where most of the time all you need to do is
iterate over the whole container, which indeed is my experience -- but
since I'm using Booch I guess it's not surprising) and an STL/Charles
view, where you give people loads of flexibility but (out of the box)
the ability to shoot themselves in the foot (eg by using iterators
from different container instancess in the same iteration.

> In other words, the question is "Why would you, the library designer,
> not want to provide an iterator subtype that is definite?"

I can't remember the exact reasons, but the driving force was probably
to have the concept of iteration defined at a high level
(BC.Container) and yet have container- and form-specific iteration.

Grady's C++ BCs have iterators defined at the specific container kind
level (eg Maps, not Maps.Unbounded in Ada terms) -- there's no
equivalent of BC.Container.

Dave Weller's Ada 95 BCs had

   type Container is abstract new Controlled with private;

   type Iterator (C : access Container'Class) is limited private;

and with each actual Container having (private) iteration-support
methods.

I changed to the present style in the 20020604 release; the release
notes say

   In response to a report from T E Dennison, speeded up the creation
   of Iterators. Note, this requires that iterators be declared of
   type Containers.Interator'Class, and initialized at the point of
   declaration.

So there was some reason for it! (I think the problem was related to
the various different kinds of state needed to support iteration for
different containers).

> It is far better to simply design the library to be flexible, and
> then allow the user to do as he pleases, without making a moral
> judgement about what is "good."  The biggest favor a library
> designer can do for a library user is to stay out of his way.

I don't quite see why (in the abstract) it's wrong to make
judgements. Most _language_ designers (except perhaps Larry Wall) make
judgements about what is good.

I think it's a matter of how far you want to go -- safety vs
flexibility. Not that I'm claiming the BCs are that safe, indeed we've
recently discussed a nasty problem with the current BC iterators
(creating an iterator over a temporary). I do see where you're coming
from, but of course the BCs are what they are and there's no point in
contemplating a major change and annoying users.