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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1108a1,93fa00d728cc528e X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,93fa00d728cc528e X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-10-19 11:20:08 PST Newsgroups: comp.lang.ada,comp.object Path: bga.com!news.sprintlink.net!howland.reston.ans.net!pipex!uunet!noc.near.net!ray.com!news.ray.com!news.ed.ray.com!swlvx2!jgv From: jgv@swl.msd.ray.com (John Volan) Subject: Re: SOLVED! Decoupled Mutual Recursion Challenger Date: Wed, 19 Oct 1994 16:35:45 GMT Message-ID: <1994Oct19.163545.4697@swlvx2.msd.ray.com> References: <1994Oct12.224944.25566@swlvx2.msd.ray.com> <1994Oct17.154812.9104@swlvx2.msd.ray.com> <1994Oct17.205244.17450@swlvx2.msd.ray.com> <1994Oct18.221751.15457@swlvx2.msd.ray.com> Sender: news@swlvx2.msd.ray.com (NEWS USER) Organization: Raytheon Company, Tewksbury, MA Xref: bga.com comp.lang.ada:7094 comp.object:7566 Date: 1994-10-19T16:35:45+00:00 List-Id: beckwb@ois.com (R. William Beckwith) writes: >John Volan (jgv@swl.msd.ray.com) wrote: >: I would >: argue that such a scheme falls into the trap of "inheritance >: collision", where one usage of inheritance (providing alternate >: programming-interface views for a single class of real-world entities) >: gets in the way of the "customary" use of inheritance (supporting >: generalization-specialization relationships between different classes >: of real-world entities). >It shouldn't because we are just added an intermediate level of >inheritance between each "customary" use of inheritance. Doing that will work -- until we have to establish a mutually recursive association between a class and *one of its own subclasses*. That was the "acid test" that I posed in my original "Challenge". Consider the Rooster class in my (admittedly bizarre) example. The Rooster class must somehow be "forward declared" before the spec of the Chicken class so that the Chicken class can include Rooster-related primitive operations. But ultimately, the Rooster class must *inherit* from the Chicken class. How can the Rooster interface be *derived* from the forwarded Rooster declaration, *and* also inherit from the Chicken interface? This is what I've been calling "inheritance collision." >But, >the effect of this is that you don't achieve true decoupling. Well, maybe we're using different definitions of "decoupling", because I'd say that your original scheme *did* in fact achieve decoupling -- except that it breaks down when pushed to the limit, because of "inheritance collision". That's why I'd encourage you to use generics for decoupling, rather than inheritance. By the way, folks, an association between a class and one of its own subclasses is *not* a rare or obscure occurrence, in fact it happens all the time. Consider, for instance, a file system, where a "directory" is a kind of "file" that can contain other "files" (including other "directories"). Another example is an object-oriented drawing editor that allows "grouping" of drawable objects. A "group" is itself a kind of "drawable object" that contains other "drawable objects" (including, perhaps, other "groups"). There are many other similar situations. Not all of these associations have to be implemented in a mutually-recursive way, necessarily, but being able to make even these associations mutually recursive *and* decoupled is the ultimate test of any scheme for decoupled mutual recursion, IMHO. -- John Volan -------------------------------------------------------------------------------- -- Me : Person := (Name => "John Volan", -- Company => "Raytheon Missile Systems Division", -- E_Mail_Address => "jgv@swl.msd.ray.com", -- Affiliation => "Enthusiastic member of Team Ada!", -- Humorous_Disclaimer => "These opinions are undefined " & -- "by my employer and therefore " & -- "any use of them would be " & -- "totally erroneous."); --------------------------------------------------------------------------------