Re: Some questions on a library design

[bobduff@world.std.com (Robert A Duff)]

In article <Pine.SGI.3.95.970617154248.6950A-100000@shellx.best.com>,
Brian Rogoff  <bpr@shellx.best.com> wrote:
>There is nothing stopping the client from storing tagged types in the 
>AGL collections, and dispatching on them in the client code. But why 
>should I have dispatching in the library when all of the container types 
>are known statically? 

I wasn't suggesting that you have dispatching in the library.  I was
suggesting that the client be able to *choose* dispatching, by creating
(e.g.) a "vector of sequence'Class", where sequence is a superclass of
vector, list, deque, etc., and then the client could iterate through
that vector, and dispatch to the appropriate *whatever* for that class.

But the client that just wants a vector of lists would get *zero*
dispatching calls.

I admit, I haven't thought this through.  But it seems like Ada's
ability to choose dispatching-vs-not-dispatching at the call site should
allow you to do what STL does in terms of efficiency, while still
*allowing* polymorphic calls to sequence operations.  In C++, you have
to choose virtual-or-not at the declaration of the function, which
constrains you a bit.

>In any case, I am deliberately copying the STL, in which dynamic dispatch, 
>benefits and all, is avoided. You may prefer the Booch components to the 
>AGL, and there is room for both (and more!).

Fair enough.  I'm just wondering if one can't get the best of both
worlds in Ada.

>I'm not sure I understand your suggestion. Do you mean pass in a generic
>formal package (which would get Red_Black_Trees or Splay_Trees) to the
>Sets package, ...

Yeah, something like that.  I guess I don't understand what you're
trying to do.  Do you want the client to be able to choose which sort of
set is used?  Or not?

>A while ago, Norman Cohen suggested "package parts" as a solution to the 
>infamous "withing problem". There have been quite a few times while I've 
>been crafting at this library that I also wished for the ability to
>interleave specs and private parts, so I certainly appreciate that
>suggestion a lot more now, outside of the context of package spanning
>mutually recursive specs!

Maybe just alternating public and private parts of a package would
suffice here?

- Bob