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,b87849933931bc93 X-Google-Attributes: gid103376,public From: dgibson@snoopy.cis.ohio-state.edu (david scott gibson) Subject: Re: Multiple Type Interfaces Date: 1997/01/29 Message-ID: <5codptINNeth@snoopy.cis.ohio-state.edu>#1/1 X-Deja-AN: 213064492 references: <5cnl86INNam9@snoopy.cis.ohio-state.edu> organization: The Ohio State University, Department of Computer and Information Science newsgroups: comp.lang.ada Date: 1997-01-29T00:00:00+00:00 List-Id: In article , Robert A Duff wrote: >What you suggest leads to multi-dispatch, no? If it must support run-time dispatching, I think so. However, I'm still interested in a purely static binding system where late binding is primarily achieved through parametric polymorphism (generics in Ada). >ALthough in a more >limited, and perhaps easier-to-deal-with form than CLOS. The whole >point of disallowing an operation to be primitive on two tagged types >was to avoid confusions related to multi-dispatch. I mean, what you're >asking for (package derivation) means that two (or more) types get >simultaneously derived, respectively, so you end up with ops on the two >(or more) derived types. Yes. I think that's a reasonable way of looking at it. But how about a package which only exports a single operation and no types. The same package extension mechanism would automatically include that operation with an identical type signature. In this case the operation would not be dispatching, at least not in the usual sense, but would still could be "inherited" through a package extension. It seems like child units support this part of package extension now. >Double (or multi) dispatch. Like I said, the >idea has occurred to me, but I haven't though it through. I *suspect* >it adds a fair amount of complexity. I'm wonder if you were to handle dynamic binding with a completely separate mechanism, if you could factor off any additional complexity which might result from package extension. BTW, I never did get any response on comp.object to my question about the need for dynamic dispatching. Aside from the issues of ease and flexibility of development and maintenance, are there any other compelling arguments for dynamic dispatching? That is, are there certain applications where the run-time dispatching approach is much more natural that any purely static alternatives? I think someone once told me that run-time dispatching is very useful for "call-back" applications or applications requiring execution of user-supplied code. Can anyone give me a more specific example and justification? Dave -- dgibson@cis.ohio-state.edu