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,acb50cdf95d3e13c X-Google-Attributes: gid103376,public From: Brian Rogoff Subject: Re: Extending A Generic Signature Package Date: 1997/03/21 Message-ID: #1/1 X-Deja-AN: 227397509 References: <5gkv23INN3rn@thalamus.cis.ohio-state.edu> <5gn90o$gm1@sutton.cs.columbia.edu> <5gtvbv$1nj@pandora.cs.utwente.nl> Newsgroups: comp.lang.ada Date: 1997-03-21T00:00:00+00:00 List-Id: On 21 Mar 1997, Geert Bosch wrote: > Alexander V. Konstantinou (akonstan@news.cs.columbia.edu) wrote: > : OO people will tell you to use inheritance, but there is > : really no reason to pay for the overhead when your abstraction > : can be served by a compile-time check. > > You shouldn't confuse using tagged types with dynamic dispatching. > Suppose you have this situation: I don't think he is. What I believe Alexander is suggesting is that the generic signature package provides an overhead free method for reusing data type specifications in new contexts. >
> > So whether a call to a primitive operation on a tagged type is dispatching or > not is determined at the call-site. I don't know why you wouldn't want to use > tagged types in your situation. The per-object space overhead shouldn't be > more than one or to pointers in most compilers. What if the objects are small, and there are very many of them? Example: your signatures are of numeric types which are the elements of matrices in a numerical linear algebra package. One or two pointers per object is too much. What if you just want to reuse the objects, which aren't tagged, and you can't rewrite them? Generic signature packages allow this. I think in answer to Alexander's question, I would reexport the ops at each level. I don't know of any approaches that satisfy your "writability" constraint. -- Brian