From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,29b1b6650a74a211 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-11-15 23:37:24 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!kibo.news.demon.net!news.demon.co.uk!demon!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: Problem with Booch iterators Date: 16 Nov 2002 07:37:25 +0000 Organization: Pushface Sender: simon@smaug.pushface.org Message-ID: References: <3dcd00f3$0$307$bed64819@news.gradwell.net> <1ec946d1.0211131139.50f479e1@posting.google.com> <1ec946d1.0211141641.2f5b6d9d@posting.google.com> NNTP-Posting-Host: pogner.demon.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: news.demon.co.uk 1037432243 18151 62.49.19.209 (16 Nov 2002 07:37:23 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Sat, 16 Nov 2002 07:37:23 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 Xref: archiver1.google.com comp.lang.ada:30972 Date: 2002-11-16T07:37:25+00:00 List-Id: mheaney@on2.com (Matthew Heaney) writes: > Simon Wright wrote in message news:... > > 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.