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: bobduff@world.std.com (Robert A Duff) Subject: Re: Multiple Type Interfaces Date: 1997/01/29 Message-ID: #1/1 X-Deja-AN: 213018747 references: <5cm4raINN6ru@snoopy.cis.ohio-state.edu> <5cnl86INNam9@snoopy.cis.ohio-state.edu> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1997-01-29T00:00:00+00:00 List-Id: In article <5cnl86INNam9@snoopy.cis.ohio-state.edu>, david scott gibson wrote: >In article , >Right, but I *do* want it to be "primitive" in the sense that it would be >included in the interface of package extensions. I *don't* want it >to be a primitive operation associated with only the single controlling >operand type (as Ada95 requires). Declaring an operand at T2'Class >was just a suggestion to try getting around the rule prohibiting >multiple controlling operands. What you suggest leads to multi-dispatch, no? 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. 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. Note that the package derivation suggested here is very different from the normal "packages as objects" and "package types" idea that various people have proposed, as a (not good, IMHO) way of extending Ada 83 to be OOP. - Bob