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,80a67c84f8039eab X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Some questions on a library design Date: 1997/06/18 Message-ID: #1/1 X-Deja-AN: 249351114 References: Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1997-06-18T00:00:00+00:00 List-Id: In article , Brian Rogoff 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