Re: Mut. Recurs. in Ada9X w/o Breaking Encaps.? (LONG)

[adam@irvine.com (Adam Beneschan)]

Magnus.Kempe@di.epfl.ch (Magnus Kempe) writes:

> John is still not satisfied that Ada 9X has a clean, elegant solution
> to his problem (two abstractions, Employee and Office, have a recursive
> dependency--how to model/implement that?).

I'd like to chime in and say I'm not satisfied either.  First, the
disclaimers: I'm just starting to learn about OO concepts and Ada 9X,
so I may not know entirely what I'm talking about.  I certainly don't
yet understand the meaning of all the new 9X syntaxes presented in the
examples.  Certainly, some of my ideas are influenced by what little I
know about Eiffel.  Also, I'm by no means an expert at language
design.

However, the solution shown feels like a "workaround", not a clean,
elegant solution.  I guess it could be called a clean, elegant
workaround.  My reasoning is as follows:

If the dependencies went only one way (an Employee contains a
reference to an Office, or vice versa), the implementation would be
straightforward.  Because there are mutual dependencies, though, a new
package Company has to be added.  This means that the package Company
is there "just to get the Ada language to do what you want", not to
represent any concept or abstraction that has anything to do with the
application.  The Company package doesn't add anything to another
programmer's understanding of how the program works--and it may in
fact be a hindrance, since it has a name that could mislead one into
thinking that it actually has some relevance.  Perhaps it would be
better to name it Aybnuiyuiwrfnkb or something.

Similarly, the example uses inheritance (type Employee is new
Employee_Parent is inheritance, right?).  As I understand it,
inheritance's primary purpose is to model "IS-A" or "IS-A-KIND-OF"
relationships between object types (I believe it's sometimes used
purely for code reuse, although that seems like a misuse of the
concept to me).  Here, inheritance doesn't really model anything--it's
just something that got set up in order to get things to work.  Like
the Company package, the use of inheritance here doesn't add anything
to one's understanding of the program.

I assume that the examples given work correctly.  I assume also that
they satisfy the really important requirement--namely, that packages
other than Employee, including Office, have access to everything the
Employee package wishes to put in its interface and to nothing else
having to do with Employees (and similarly for Offices).  Thus, this
is certainly an acceptable workaround for the problem.  But "clean"
and "elegant"?  Maybe I'm being too much of a purist, but I have
trouble characterizing something that requires adding this much code
that has no meaning to someone reading the program, as elegant.  It
seems more like a flaw in 9X that things have to be done this way.
And based on my experience writing large Ada 83 programs, my gut
instinct is that this is the sort of flaw that will be cursed by many
9X users down the line.  I also realize that if we tried to make Ada
9X absolutely perfect, it wouldn't be Ada 9X any more but something
like Ada 23.  :-)

What I think John wants (and I concur) is some way for package
specifications to use accesses to types in other packages that haven't
been compiled yet--sort of like a forward declaration that crosses
package boundaries.  Perhaps something like this could be added to 
Ada 0X or whatever the next revision of the language would be.

    with ...;         -- other stuff
    without Office;   -- "without" means that we're referring to a
                      -- package that hasn't been compiled yet 
    package Employee is
       ...
    private
       type Object is tagged record
          ... -- various components involving that "other stuff"
          Its_Occupied_Office : Office.Pointer;
              -- here we're promising that when Office is compiled,
              -- there will be an ACCESS type named Pointer.  This
              -- will be verified at link time.  
       end record;
    end Employee;

Oh well, just my 2 cents . . .

                                -- Adam

(P.S. John, how about we get together and start our own church?  :-)


--
The above views are my own and do not necessarily represent those of
Irvine Compiler Corp.