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.3 required=5.0 tests=BAYES_00,INVALID_MSGID, YOU_INHERIT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,56dbd715fa74735a X-Google-Attributes: gid103376,public From: Matthew Heaney Subject: Re: Mutually dependent private types Date: 1998/05/26 Message-ID: #1/1 X-Deja-AN: 356888347 References: <6k25ra$6j7$1@nnrp1.dejanews.com> <3565B105.9BFB4788@ac3i.dseg.ti.com> <356B226F.EF05E927@ac3i.dseg.ti.com> Organization: Network Intensive Newsgroups: comp.lang.ada Date: 1998-05-26T00:00:00+00:00 List-Id: John Volan writes: > Matt, in your original example, you had T1 and T2 (and T1_Rep and > T2_Rep) all derive from a common Root type. That looks a lot like the > idea of having a universal root type that everything derives from. (My > real objection to your example was that you declared T1_Rep and T2_Rep > in a common *package*, which I thought was unnecessary.) You are correct - I was wrong to do this is my original response. Note that I declared T1_Rep and T2_Rep in the same package because I thought Adam required that each type have visibility to the other type's representation. If that wasn't the case, then I agree with you that it's better to move each "forward" type into its own package. > As you point out yourself, this spurious > polymorphism creates an opportunity where someone could try (either > accidentally or maliciously) to provide more than one full type for the > same "forward" type. Yes, but let's talk about reality. While it's _theoretically_ possible for a programmer to wrongly inherit from a forward type, in practice it'll never happen. package Employee_Forward is type ONLY_EMPLOYEE_BETTER_INHERIT_FROM_THIS is abstract new Person_Type with null record; end; > Furthermore, what if you're already using inheritance to support true > polymorphism, and then you discover you need to break a mutual > dependency somewhere in your class hierarchy? You might end up with a > situation I call "inheritance collision": That's where you're trying to > apply Ada's inheritance mechanism for two competing purposes, but you're > faced with the fact that Ada only supports single inheritance. Sure, > it's possible to wiggle your inheritance hierarchy around so that it'll > work and you can still keep your mutually-dependent types in different > packages. But I find that to be awkward and artificial. If you have deep or otherwise "complex" type hierarchies in Ada, then you're doing something wrong. Hierarchies should be shallow. When I hear stories about problems someone is having with their inheritance hierarchies, I become suspicious, because it often indicates that the programmer is fighting the langauge. The "proper" style of object oriented design advocated in popular books and journals mostly does NOT apply to Ada 95. Much of the advice out there (especially wrt inheritance) applies only to languages in which the size of the object is known up front (ie the type has reference semantics, and therefore it's just an address). This is not the case for Ada, because types in Ada have value semantics, and so their size isn't known up front. This makes a type low in the hierarchy _extremely_sensitive_ to perturbations of ancestor types. As I explained in a post to cla a few months back, this seemingly innocuous detail has overarching consequences for the design of software systems written using Ada. Very few Ada programmers really understand this, and they often have "problems" with their inheritance hierarchies, compilation depencies, etc, etc. (A friend mine who came from a C background noted that you can always tell who the Ada programmers are, because "they're the ones reading a newspaper at their terminal." He was observing that Ada programmers often have to wait a long time for their compiles to finish - a sure sign of design problem.) > Bottom line, I don't think anyone can legitimately claim that Ada95 > offers a solution to mutual dependency problems "right out of the box". > All you can say is that there are various workarounds, with varying > degrees of awkwardness, that can be used to make up for a fundamental > hole in the language. I'm not disagreeing that "workarounds" are required, but I feel this whole "with'ing problem" has been blown way, way out of proportion. The technique described in Norm's book is very simple, and doesn't _in_practice_ compromise type safety. > But a simple case > of mutual dependency shouldn't call for polymorphism. I'm not disagreeing, but what are you going to do? This is the language we've got _today_, so accept it. If it bothers you that much, then turn the tag check off! > Depends on the style of software design you're using, which depends a > lot on your programming culture. I'm talking about Ada 95. That there are design idioms specific to Ada, and that one has to actually go out and learn these idioms, doesn't bother me. If your inheritance hierarchies are causing you problems, then it's a sign that maybe your design is not suitable for implementation in Ada. I'm a firm believer in designing _to_ the language. I'm not disagreeing that, because you can't have mutual dependencies in Ada, that this can cause an unnatural mapping to a language (as Java) that does allow mutual depencency. And I'm not disagreeing that this is a Bad Thing, especially since Ada is advertised as "easily" interfacing to other languages. But this "withing problem" is just not that big a deal. Matt