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,e9ec140e4d84359f X-Google-Attributes: gid103376,public From: mab@dst17.wdl.loral.com (Mark A Biggar) Subject: Re: No multiple dispatch in Ada95? Date: 1995/04/06 Message-ID: <1995Apr6.163750.11289@wdl.loral.com>#1/1 X-Deja-AN: 100939404 sender: news@wdl.loral.com references: <3lu8tp$eep@disunms.epfl.ch> organization: Loral Western Development Labs newsgroups: comp.lang.ada Date: 1995-04-06T00:00:00+00:00 List-Id: In article <3lu8tp$eep@disunms.epfl.ch> matomira@di.epfl.ch (Fernando Mato Mira) writes: > I checked the reference manual. There's no multiple dispatching >in Ada95? > I see no reason why a left-to-right disambiguating rule was not good enough. > You only add the extra dispatching complexity when the methods defined >require it. And it should be faster than simulating it by >a `double dispatch'. What's worse, time is already wasted checking >for a Constraint_Error. The major reason for leaving out multiple dispatch is that given the limitations that would have to be put on it it would be practically useless. Note that the only dispatching operations in Ada95 are the primitive operation of the tagged type and those can only be defined in the same package spec as the tagged type declaration itself and even then only until you do something to freeze the type (like derive another type from it). So once you derive a new tagged type from an old one you can now longer define dispatching operaton on the parent type. This means that if, for example, I had tagged types A and B with new type C derived from A and D derived from B and the multiple dispatching operator F(A, B), then only new dispatching version I can define is F(C, D). If I define F(A, D) it wouldn't be dispatching on A and likewise F(C, B) wouldn't be dispatching on B. And even then all that would have to be defined in the same package spec. Basically adding multiple dispatch to the language would require redisigning the whole tagged type system. >PS: And why not reaping the benefits of both single inheritance > and contract-based design by restricting inheritance to > only one parent with structure plus an arbitrary number of abstract > parents with null records? That solves the duplicate data member problem but doesn't solve the duplicate operation problem. -- Mark Biggar mab@wdl.loral.com