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: 109fba,66253344eaef63db X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,66253344eaef63db X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,66253344eaef63db X-Google-Attributes: gid1108a1,public X-Google-ArrivalTime: 1994-10-12 15:00:48 PST Newsgroups: comp.lang.ada,comp.lang.c++,comp.object Path: bga.com!news.sprintlink.net!howland.reston.ans.net!swiss.ans.net!solaris.cc.vt.edu!MathWorks.Com!noc.near.net!ray.com!news.ray.com!news.ed.ray.com!swlvx2!jgv From: jgv@swl.msd.ray.com (John Volan) Subject: Re: Mut. Recurs. in Ada9X w/o Breaking Encapsulation? Date: Wed, 12 Oct 1994 21:18:20 GMT Message-ID: <1994Oct12.211820.23051@swlvx2.msd.ray.com> References: <1994Oct8.171744.26604@swlvx2.msd.ray.com> <377t87$t7n@network.ucsd.edu> Sender: news@swlvx2.msd.ray.com (NEWS USER) Organization: Raytheon Company, Tewksbury, MA Xref: bga.com comp.lang.ada:6823 comp.lang.c++:32551 comp.object:7289 Date: 1994-10-12T21:18:20+00:00 List-Id: mbk@inls1.ucsd.edu (Matt Kennel) writes: >John Volan (jgv@swl.msd.ray.com) wrote: >: I don't want to get into a language war either :-), but I wouldn't go >: so far as to say that those languages have the "best of both worlds." >: Every language embodies certain trade-offs. Eiffel does do a nice job >: of decoupling mutual recursion, but at what cost? An Eiffel class >: text includes both the interface and the implementation of that class. >: Presumably, an Eiffel compiler ("language processing tool") is smart >: enough to automatically sift interface from implementation and >: determine dependencies between classes, by making as many passes >: through class texts as it has to. So this relieves Eiffel programmers >: of the burden of separating interface from implementation and making >: decisions about intermodule dependencies. In fact, I would wager that >: most Eiffel programmers are unaware of these issues. But is this >: necessarily a good thing? >If it's dependent, it depends. What are you supposed to do about it? >Are you just supposed to be punished for having certain kinds of >dependencies? Matt, by your own statements, I think you actually prove my point for me. As an Eiffel programmer, you seem to be unaware of the effect of dependencies. It's not a matter of "punishing" a programmer for introducing dependencies. The dependencies are there, whether you program in Ada or in Eiffel. It's just that they're more *obvious* in Ada, because you're forced to state them explicitly. >: My feeling is that Eiffel programmers are >: less conditioned than Ada programmers to think first in terms of the >: abstractions in the problem, and are more prone to leap ahead into >: implementation details. >No, perhaps Eiffel programmers think about abstract classes first >which can have many implementations substitutible at run-time. Ah, but you see, I'd say that was using the notion of "types" and "abstract types" to *simulate* something else that has more to do with "modules". When we talk about writing a spec (interface) before writing a body (implementation), all we're usually trying to do is to state, up front, the contract for some *concrete* software component. (Perhaps that contract involves inheriting the contract of some more abstract software component, but that's a different story.) You're saying that in order state this contract, I have to artificially introduce *another* component (with a different name, no less) that acts as an abstraction. Moreover, by introducing an abstract class, we introduce an added complexity: We open up the possibility that someone may later introduce other concrete classes, with different implementations, all inheriting the abstract class, and all possibly intruding into the application. What if the original problem did not demand multiple contending implementations of a particular component, but in fact demanded that it be implemented only *one* way. Understand what I mean: We might very well imagine, and even test out, different implementations of the component, but in the final fielded system we must choose only one. But the *clients* of that component *don't care* and *shouldn't care* which implementation it is. All they care about is the contract. They shouldn't have to explicitly name which implementation they're using. The component itself should hide that choice within it. Using abstract classes just to express interfaces seems like a lot of added complexity to simulate a very simple idea. (Of course, it's a truism that what is simple to do in one language may not be so simple in another language -- sort of like saying "Capitalism is man's exploitation of man; whereas Communism is the reverse." :-) But the point really is, how are Eiffel programmers being conditioned to think? In order to get them to think about separating out the contract first before jumping into implementation, they have to get wrapped up into all sorts of issues about abstract types and inheritance and all that. Do Eiffel programmers really delve that deeply all the time? (You know, I could just as easily ask why Eiffel "punishes" programmers in this way, forcing them to write nasty evil abstract classes all the time ... but I won't, 'cause I'm a nice guy! ;-) >: And because "being dependent on another module >: within your own interface" isn't distinguished from "being dependent >: on another module only within your own implementation", I think Eiffel >: programmers are going to be less sensitive to how module dependencies >: impact the cost of development, in terms of time spent recompiling >: after changes, and so forth. >That's the downside? You mean, you don't think that's bad enough? Perhaps you haven't had to work on truly *huge* projects, with dozens or hundreds of engineers working on hundreds of thousands, or perhaps even millions of lines of code. If you ever had to make a one or two line change and then had to wait for a few hundred thousand lines of code to be recompiled, I think you'd learn pretty darn quick about the difference between an "interface dependency" and an "implementation dependency." (Well, I can't say I've actually been in a situation *that* bad, but I can imagine it happening a lot more without Ada there to help! :-) >I still don't see why having separate chunks of something for interface and >implementation should necessarily disallow mutual dependencies. It's >perplexing why you just can't say Ada 9x shall now allow mutual dependencies >among interfaces or implementations. Well, I think you'll have to take that up with the language designers and the compiler writers. Anyone want to chime in here? :-) >If they each depend on each other, you can't make that go away; except >perhaps by making both depend only upon an intermediary, as with >the TWO_WAY_RELATION{EMPLOYEE,OFFICE}. >Still, there's a mutual dependency there as OFFICE depends on >TWO_WAY_RELATION{} and TWO_WAY_RELATION{} depends on OFFICE when >instantiated with type parameters. >I think cyclic dependency graphs are a fact of life. Oh, I fully agree that cyclic dependency (mutual recursion) is often unavoidable. But again, I think you prove my point for me about Eiffel programmers -- you don't seem to be able to see the difference between dependency-in-your-interface vs. dependency-in-your-implementation. >-- >-Matt Kennel mbk@inls1.ucsd.edu >-Institute for Nonlinear Science, University of California, San Diego >-*** AD: Archive for nonlinear dynamics papers & programs: FTP to >-*** lyapunov.ucsd.edu, username "anonymous". -------------------------------------------------------------------------------- -- 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."); --------------------------------------------------------------------------------