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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,c52c30d32b866eae X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,2ea02452876a15e1 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,c52c30d32b866eae X-Google-Attributes: gid1108a1,public From: schlegel@informatik.uni-rostock.de (Juergen Schlegelmilch) Subject: Re: Real OO Date: 1996/05/08 Message-ID: #1/1 X-Deja-AN: 153738301 references: <4moh63$i0b@nntp.Stanford.EDU> organization: Comp Sci Dept, Uni Rostock, Germany reply-to: schlegel@Informatik.Uni-Rostock.de newsgroups: comp.lang.eiffel,comp.lang.ada,comp.object Date: 1996-05-08T00:00:00+00:00 List-Id: On Wed, 8 May 1996 07:49:05 GMT, Don Harrison wrote: > > One way of controlling both the ambiguity and combinatorial explosion problems > would be to only require that an implementation be provided if actually used. > That is, if a call is made with a specific combination of actual parameters. > > If this can be determined statically (difficult), then it could be required as > a static constraint for a statically typed language. If not, then it could be > imposed as a dynamic constraint for both statically and dynamically typed > languages. In this case, an exception would be raised if the specific > implementation corresponding to a parameter combination is not found. There is a technical report from Craig Chambers and Gary Leavens (Iowa State University, Aug 1995) about type checking multi-dispatched methods statically (in the Cecil language). The algorithm presented in the paper is not exponential, and finds all possible conflicts at compile time. I think this is what you are searching for. It will allow you to supply only the implementations you found necessary, run the type checker and add further implementations as required for safe dispatch; the additional implementations are either really necessary (i.e. the combination of classes can occur in your program) and you simply forgot them, or they are not needed because you know (how?) that the associated combination of classes will not occur, so you have to give the type checker more information. Note that this latter approach is not covered in the paper. I don't remember whether the algorithm suggests a minimal number of additional implementations, or just a set of implementations that will resolve all conflicts. > I think I prefer the dynamic approach. In the context of Ziggy, failure to > dispatch as a result of broken multiple dispatching would simply be another > manifestation of broken polymorphism. System level validity checking would > be a runtime phenomenon. Yes, dispatch failure for multiple dispatch indicates broken polymorphism. The design of inheritance hierarchies is often not seen in the light of the Liskov Substitution Principle, but rather under the aspect of code reuse. This may lead to hierarchies in the sense of taxonomies (i.e. specialisation by restriction) which make polymorphism a difficult thing. Multi-dispatch adds to these difficulties by breaking up the object/class- centered view: you have to consider combinations instead of single objects. I hope this helps a bit. Juergen -- +-----------------------------------------------------------------------------+ Dipl.-Inf. Juergen Schlegelmilch University of Rostock email: schlegel@Informatik.Uni-Rostock.de Computer Science Department http://www.informatik.uni-rostock.de/~schlegel Database Research Group Tel: ++49 381 498 3402 18051 Rostock Fax: ++49 381 498 3404 Germany +-----------------------------------------------------------------------------+