Re: Mut. Recurs. in Ada9X w/o Breaking Encapsulation?

[jgv@swl.msd.ray.com (John Volan)]

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.");
--------------------------------------------------------------------------------