Re: Interface/Implementation (was Re: Design by Contract)

[Samuel Mize <smize@link.com>]

[reformatted for line length]

Don Harrison wrote:
> 
> Matthew Heaney wrote:
> 
> :In article <EG4KGI.ILG@ecf.toronto.edu>, doylep@ecf.toronto.edu
> :(Patrick Doyle) wrote:
> :
> :>>The Eiffel camp seems to think that dependency order is a
> :>>limitation, but it was a deliberate decision by Ada's designers.
> :>>As an Ada programmer, I haven't found it to be a limitation at
> :>>all; in fact, I find it quite helpful, exactly as the designers
> :>>imagined it would be.
> 
> That's interesting because I find it a hinderance more than a help for
> a number of reasons:
> 
> 1) The most important reason is that compulsory backward references
> force the developer to order everything (apart from things defined
> in the spec) from low level to high level. This is the exact
> opposite of what a human reader needs to comprehend the body in a
> linear top-down pass. It's far easier for them if high level stuff
> is declared first and low level implementation detail progressively
> lower down. That way, they can readily grasp the high level picture
> at a more abstract level and, if they require more detail, they
> can read on.

I'm rather an Ada bigot, but you have convinced me that, if people
were reading large packages or procedures as linear text, this would
be a good approach, perhaps even a better approach.

As several people (including Don) have pointed out, if you try to
read an Ada unit with a lot of sub-procedures, you wind up reading
it from the end backward.

As nobody has yet pointed out, you're not going to read and
understand this large a code artifact in one pass anyway, so
the ordering is largely irrelevant.  You need to be able to
FIND referred-to elements, but it neither helps nor hurts that
all references are to earlier items (especially when the
earlier item may be a forward declaration to a later item).

So I would agree that the read-in-one-pass argument in favor
of dependency ordering is weak, at best.


> 2) It's problematic when an exported feature is removed from the
> spec (perhaps because it's erroneously exported) and you have to
> re-order the body to accomodate dependencies.

You can simply move the procedure specification (the part that
appeared in the spec) to the start of the body, with an
appropriate comment.

>If you're not the author of the body, you have to
> work out the particular scheme used and find an appropriate spot
> for it.  This may not be straighforward and is also likely to cause
> a ripple effect because operations the operation itself depends on
> may subsequently have to move. I find the trial-and-error nature of
> this activity incredibly annoying.

If it's a trial-and-error process, then the design isn't correctly
structured for this kind of organization, and you definitely SHOULD
move the procedure spec to the head of the body.

I'm not saying such a design is necessarily BAD.  It may be a case
where dependency ordering is helpful, so you shouldn't try to use
it.  I've seen well-designed Ada packages where the body starts by
forward-declaring all the internal procedures, so they can use
each other.  A recursive descent parser might be coded this way.

I find it helpful to see, up front, which things are 

> 3) It's also problematic in the case of mutually recursive types
> and operations.  You are forced to pre-declare those that are
> forward referenced.

This is in fact one of the arguments in FAVOR of dependency
ordering: it prevents accidental mutual recursion, and documents
your intent for maintenance coders.

- - -

I find that Ada's dependency ordering provides a useful level
of organization in many cases, and that it is helpful to have
forward declarations as an explicit indication that this ordering
rule is being abandoned.  However, that may just be because I'm
used to it.  Certainly you can order your declarations this way,
if it improves clarity, in a language that doesn't require it.

Sam Mize