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,2ea02452876a15e1 X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Choice of OO primitives in Ada95 Date: 1996/02/23 Message-ID: #1/1 X-Deja-AN: 140848030 references: <4gc2pu$6qj@ux1.lmu.edu> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-02-23T00:00:00+00:00 List-Id: In article , Don Harrison wrote: >Ray Toal wrote: >:Requiring 'tagged' is a GOOD THING! Inheritance weakens encapsulation. > >Not sure what you mean by this. Inheritance is no weaker or stronger in languages >(such as Eiffel) which map classes onto the encapsulation mechanism. He didn't say "inheritance" is weaker, he said "encapsulation" is weaker. That's clearly true -- when you see a function call that cannot dispatch, you know for sure exactly what it does. When you see a dispatching call, it might go off and do something you've never heard of. If there's no dispatching, then a single abstraction is completely encapsulated, whereas with dispatching, an overriding function can sneak in and do buggy things. Dispatching is a powerful feature, but it has this cost. If you use dispatching when you don't need it, you are paying that cost without getting any benefit. Therefore, it makes sense to give the programmer the choice. Note that Eiffel seems to agree with this, to some extent -- otherwise, the "frozen" (or whatever it's called) thing wouldn't exist. Of course, the counter-argument is that you don't always know ahead of time when you might need dispatching. I'm not sure I agree with Ray Toal, though, that requiring "tagged" is a Good Thing. Even without that rule, Ada still gives you control over whether things dispatch, on a call-by-call basis. So, I view "tagged" as simply an efficiency hack. Efficiency is a Good Thing, too, though. >Yes, it's called Eiffel and it's great having such flexibility! :-). One aspect >of that flexibility is that, if, one sunny day, you decide you need to extend a >type you go right in and do it and don't have to touch the original. Well, that's not *really* true. You quite often have to go back and change the original, because you're doing something new that conflicts with assumptions made by the original. >... In Ada, you >have to go back and redefine the type to make it tagged. The impact of this may >be limited to that - don't know, haven't thought about it - but you shouldn't have >to redefine something to reuse it. I pretty much agree with that. You can, of course, make all your types tagged in the first place, and then you won't have that problem. >: Whether or not a type >:should be tagged is a DESIGN decision; I totally disagree that it >:should be an implementation decision. By the way a compiler can not >:in general determine if the "type is extended elsewhere" since in >:Ada extensions can appear in other compilation units. > >I can't think offhand of a suitable way of dealing with this but that isn't to >say it's impossible. It is clearly possible to do at link time, and clearly impossible at compile time, given separate compilation. >You don't have to do it that way. You can use (for example) a synonym construct like > > procedure P, Q (X: T) is begin R(X); end P, Q; > >and redefine Q for extensions of X. Yes, that's another reasonable way to do it. - Bob