Re: How to Use Abstract Data Types

[eachus@spectre.mitre.org (Robert I. Eachus)]

In article <6ib2o9$4gq$1@nnrp1.dejanews.com> adam@irvine.com writes:

 > Also, when you say that the body of Iterator calls abstract primitives
 > on Libraries, I don't see how those primitives would be written.  It
 > seems like the abstract primitives I'd have to define in Libraries
 > would be, essentially, the same Scan_By_Title, More_Books, Next_Book,
 > etc. routines I already tried to define, and those would have the same
 > problem with OUT parameters that I already complained about.

   No problem.  That went away when I moved the type Book out of the
Libraries package.  In some other OO languages that sort of confusion
between classes is necessary.  In Ada, such a confusion creates many
more problems than it solves.

   Note that if your model requires a special Amazon_Book type, that
is fine.  You derive it from Book, and the functions can return
Book'CLASS.  In fact if you look at my example, Next returns
Book'CLASS.  The function is not polymorphic on Book, but its return value can
be any type derived from Book.

 > So it seems like all you've done is pushed the problem one level
 > back.  I'll grant that you could implement these primitives
 > (perhaps in the private part of Libraries) using a "dirty" method
 > that uses accesses to the abstract types as OUT parameters, and
 > provide Iterator as a "clean" interface to the outside world to
 > avoid the dirty stuff.  Is this what you were getting at with your
 > response?  (Personally, though, I don't see much benefit from
 > adding this extra layer.)

   No dirty methods required.  The reason for providing the
 abstraction is so that you can override the methods that require it,
 and inherit others, concealing those details from the user of the
 abstraction.

  > Unfortunately, you've reduced some flexibility by doing this, because
  > there's no guarantee that Process_Book (whatever it is---you haven't
  > defined it---is it a generic subprogram parameter?) is going to be
  > easy to write.

    Of course there is no such guarantee.  Your Amazon.com example
shows why.  I was just showing that the easy cases could be handled by
default. 

 > I often define iterators as four routines (initialize,
 > test-for-more, get-next, close) instead of, say, writing a generic
 > "do-this-for-all-the-books" routine (or a "do-for-all" routine that
 > takes an access-to-subprogram parameter), precisely to give myself
 > this flexibility.  For example, I might want to stop the iterator
 > after 10 books, because I only have room on the screen to display 10,
 > and I want to wait for the user to input a "go to next page" command
 > before bothering to retrieve the next 10.  This would be especially
 > necessary when FTP'ing from amazon.com; you don't want to have to
 > query for the entire set of matches until you know you'll need them.
 > Or, maybe I want to display three books on each line...

   All possible complications, or you might have five different
iterators based on these differing requirements.  The point is that
you would write the five iterators once each, the however many library
abstractions once each, and the same for books.  You would never have
to code the m by n by p possible combinations.

   And that is the key concept to grasp here.  Ada provides several
different methods for creating classes of objects.  They can all be
designed to compose with each other.  But if you confound classes,
like the Amazon library and Amazon books above, then they don't
compose.  A Barnes_and_Noble library class couldn't use the Amazon
book class, and more important, adding CDs to the program would
require changes all over.  In Ada keep separate abstractions separate
wherever possible.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...