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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8a4c4f5d7ace34fb X-Google-Attributes: gid103376,public From: Brian Rogoff Subject: Re: Subject: Active Iteration (was: How to use abstract data types) Date: 1998/05/08 Message-ID: #1/1 X-Deja-AN: 351457034 References: <6iq9cl$i3t$1@nnrp1.dejanews.com> Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: 894642679 20301 bpr 206.184.139.132 Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1998-05-08T00:00:00+00:00 List-Id: On Fri, 8 May 1998, Matthew Heaney wrote: > In article <6iq9cl$i3t$1@nnrp1.dejanews.com>, adam@irvine.com wrote: > (start of quote) > Anyway, it kind of surprises me that the solution involves a generic > that takes subprogram parameters. The reason it surprises me is this: > based on what I thought OO was "supposed" to be, I expected that the > routines in Library_Package, including the ones that step through the > iterator, would be dispatching routines. That is, at some point the > code would have to select which routine to call, i.e. perform an > indirect subroutine call; I expected this to take place through the > dispatching mechanism, rather than through a generic formal subprogram > (the Ada 83 way?). Having to use a generic to handle something I > thought polymorphism should be able to handle is a bit disappointing > to me. > (end of quote) > > ... snip ... > My other reason to the generic approach is to try an convince people that > you don't always need completely dynamic behavior. There are times where > you know up front what the specific types are, and so the generic approach > works just great. This isn't the "Ada 83" way, it's just the "Ada" way. A laudable approach IMO. Another approach involving genericity and not possible in Ada 83 involves the use of (null bodied) generic signature packages to abstract the iterator interface. This solves one of the "Ada nasties" mentioned by J. Bishop in her article on implementing iterator abstractions (I forget the ref, some IEEE journal of around 1990) using Ada 83 generics, the nasty being that it wasn't possible to have many implementations for a given generic interface. The other Ada problem of course involved procedure parameters and is partially fixed by procedure access types (and fully fixed in GNAT). -- Brian