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

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

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

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

[Robert I. Eachus]

In article <1994Oct12.211820.23051@swlvx2.msd.ray.com> jgv@swl.msd.ray.com (John Volan) writes:

  >> 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 gazelles had longer necks and ran slower they would be giraffes?

     Any language has "fundamental theorems" in its design. (Or at
least a language should, some languages have "just grown".)  If chosen
properly, these basic rules provide a consistancy to the language and
make it more useful in the languages intended domain.  One of the
fundamental theorems in Ada is that there exists a consistant
elaboration order, where everything is declared before it can be named
and elaborated before it can be used.

     This is one of the nicest properties of Ada from  a debugging and
maintenance viewpoint, but it does impose some costs on programmers.
For example, incomplete type declarations are needed if you are
declaring a type that is indirectly self-referential.  (The typical
case is a record type containing pointers to other records of the
type.)

     So if you want a language that allows use before elaboration,
choose another language.  (Notice that Ada does allow--but does not
require compilers to support, due to halting problem issues and
intractability--deferring the selection of an elabortation order until
run-time and then "selecting the one that works today."  The only
thing that is definitely forbidden is referring to a yet to be
initialized portion of a construct.  Since types have attributes, and
these attributes do need determination, types also require
elaboration.  It may seem silly that the fundamental reason that you
can't have directly recursive types in Ada is that you have to
determine the size of one type before the other, but that is the way
it is. (There is a restriction on the use of incomplete type names in
3.8.1(4), and a restriction in 8.2(16) on visibility to prevent
directly recursive types.)

  >>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.

   Just to make sure I don't confuse the issue, there is no problem
implementing recursive structures in Ada.  The only limit imposed by
all the above is that the mutual recursion must be expliciltly
indirect in the implementation--it can be, and often is, direct in the
interface.  For example in a tree package you might have:

   function Parent(N: Node) return Node;

or if edges are important:

   function Parent_Link(N: Node) return Edge;
   function Destination(E: in Edge) return Node;




      

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

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

[Fred McCall]

In <1994Oct8.135052.10923@inca.comlab.ox.ac.uk> lady0065@sable.ox.ac.uk David J Hopwood writes:

>Absolutely right. The difference between C++ and Ada9X in this case is that
>Ada9X has separate compilation, and C++ doesn't. 

Since when?  Every C++ compiler I've ever used had separate
compilation.  Perhaps you've redefined the word since I went to school? 


--
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
---------------------------------------------------------------------------
merlin@annwfn.com -- I don't speak for others and they don't speak for me.