From: nospam@thanks.com.au (Don Harrison)
Subject: Re: Interface/Implementation (was Re: Design by Contract)
Date: 1997/09/09
Date: 1997-09-09T00:00:00+00:00 [thread overview]
Message-ID: <EG8CAy.B21@syd.csa.com.au> (raw)
In-Reply-To: dewar.873630067@merv
Robert Dewar wrote:
:Don says
:
:<<IMHO, this is how it should be. One of the annoying things I find with the
:ability to order operations differently in Ada spec and body is that you
:see them in a certain order in the spec and may have trouble finding them
:in the body because they've been re-ordered, often due to compilation
:dependencies. IMO, there's no excuse for imposing dependency-related ordering
:in an age of multi-pass compilation.
:
:Does the Ada95 standard impose dependency-related ordering?>>
:
:No, and neither does the Ada 83 standard in this context, so your comment
:about finding this annoying is simply confused.
Yes, as you say, operations etc. declared in the spec can be freely ordered
in the body. My mistake.
What I'm referring to, is the fact that depedendency-related ordering is
imposed for elements (operations/types etc.) declared and used in the *same*
spec or the *same* body - a different issue, as you say below. (More on
this at the end).
:We are talking about the order in the body of entities declared in the spec.
:Clearly these have all been previously declared, so the order of subprogram
:bodies in the body of the package is completely free, I have no idea what
:you are talking about.
While the order of elements previously declared in the spec is free, the
order of elements declared in the body is not, which, though explicable, is
inconsistent.
:If you see a different ordering in the spec than in the body, it is not
:because of "compilation dependencies", it is because the programmer thinks
:this is a good idea..
[..]
:On the other hand, you never need to browse the body as a client of the
:package, so the logical ordering requirement for such browsing does not
:apply. The two files are viewed VERY differently in an Ada environment,
:not only will different people touch them, but different people will look
:at them, and the client of a package should almost never be looking inside
:the body -- if they need to, it shows something is wrong with the spec.
The client and the implementer are not necessarily different parties. For
example, for a maintainer of a package whose spec and body were written by
different people, it can be annoying to find them ordered differently.
At least, that is my experience.
:Incidentally the separate files aid this goal. An Ada programmer expects
:to find everything they need in one file, and is definitely annoyed, and
:knows that there is a bug, if they have to go and look at the body. If you
:put things in one file, even a single file with different views, it is far
:too easy for programmers to get in the habit of looking at this file without
:going though the restricted interface view, and thus not to be sensitive
:enough to enforcing the separation. Yes, tools could make this harder, but
:in practice, not everyone is using such tools, and it is all too easy for
:a client to easily browse the implementation.
In the case of Eiffel, commercial implementations *do* provide a short
form tool, so storing interface and implementation in separate files isn't
necessary.
:Going back to the ordering issue, in the body, I usually prefer to arrange
:the subprograms in alphabetical order, because this is easier for reference
:purposes for the implementor who needs to go to a particular body to debug
:or otherwise fiddle around.
My own preference is to organise along functional lines in both spec and body.
That way, related operations get grouped together and you can often just scroll
up or down to look at what you're interested in.
That's why I have no problem with consistent ordering being enforced.
However, forcing consistent ordering doesn't necessarily mean that you
can't *access* in some other order. An Eiffel implementation could provide,
for example, a "very short form" consisting of just feature names. Feature
ordering in the window could be changed in just the same way as you can select
different directory views in a file manager. Possible feature views might be:
a) Same as short form (the default)
b) Alpabetical
c) Most recently updated
d) etc.
With such a capability, forced consistent ordering would not be the end of
the world if you prefer some other view.
:That's the *crucial* difference between the spec and the body, the spec gets
:browsed as a whole, the body never does.
Not if you order on functional lines, in which case, *sections* may be browsed
as a whole. BTW, wouldn't it be hard to maintain alphabetical ordering when you
add operations specific to the body? - you would lose your ordering due to
dependencies.
:I quite see how Eiffel programmers,
:or other programmers not used to this strong separation would not see the
:benefit of being able to organize the two objects differently, you do not
:miss what you do not have.
OTOH, I can see why Ada programmers might consider this more of an issue
because they are dealing with modules of typically coarser granularity
than Eiffel programmers. In the case of co-encapsulation, Ada modules map
one-to-many to abstractions, potentially giving rise to many features.
It's less of an issue in Eiffel because modules correspond one-to-one to
abstractions.
:One of the most widespread weaknesses, even among experienced professional
:programmers, is the inability to comprehend the importance of separating
:specification from implementation. Note tha the entire "comments are useless,
:my code is self documenting" view is fundamentally at odds with this basic
:requirement of separation.
Sorry, don't see the connection. Can you explain?
:Yes, you can separate effectively in any language if you work hard enough
:(the equivalent of a separate spec can be created entirely by commenting
:even in a language like COBOL or BASIC with absoslutely NO avbstraction
:capability of this sort), but in practice, a language like Ada where this
:separation is very strong will encourage more programmers to understand
:the importance of the separation. In the Ada world, absolutely everyone
:understands that you should be able to use a package only looking at its
:spec and not its body, and the fact that the spec can be handled separatly
:as a coherent compilable entity is one of the most important aspects of
:Ada, since it leads even inexperienced not very competent programmers
:to fully grasp the importance of the separation of spec and body.
I can assure you Eiffel developers place just as much importance on the
interface as Ada programmers.
With the exception perhaps of the ordering argument (which itself is not very
strong, IMO), all of the arguments I've seen advanced in favour of separate
interfaces are not intrinsically that at all. They are arguments in favour
of being able to *distinguish* between interface and implementation. While
these arguments are perfectly valid, they're incorrectly passed off as
supporting separate interfaces. They're not.
For the purpose of those arguments, how the interface came about is immaterial.
It doesn't matter whether it was written first or generated from the
implementation. The claim that you need separate interfaces to realise the
benefits of distinguishing between them is bogus.
:<<dependencies. IMO, there's no excuse for imposing dependency-related ordering
:in an age of multi-pass compilation.>>
:
:Though this technical point is completely irrelevant to the main thread
:of discussoin here, if you are saying that you should be able to use entities
:before they are declared. I strongly disagree. Sure my compiler can make
:multiple passes through a source document, but as a human reading the
:document, I prefer not to. There is a reason why we arrange text books,
:and other materials not to have forward references (such as mentioning
:a character in a novel before introducing them). Programs benefit in the
:same way from a basically linear approach, in which overall understanding
:can be obtaineed in a single linear pass.
I agree to the extent that I think a linear pass is useful for gaining an
overall impression of what a program does. Consequently, I agree with the
recommended Eiffel style of identifying broad categories of functionality
which are consistently applied and ordered in all classes. It's then easy
to gain a broad-brush view of a class by scanning it linearly.
However, once a reader has gained such an impression, they typically want
to move from sequential to direct access, more like consulting an encyclopaedia
than reading a novel. (I think someone has already mentioned this). In that
case, what they want to do is to jump around within the text with the aid
of the string search facility of the underlying editor. They get a bonus
if the implementation is ordered along functional lines because they can
scroll as well.
Incidentally, well-written technical books may be read this way as well.
Eliminating dependency-related ordering has another advantage: removing the need
for redundant pre-declarations (for me, another of Ada's little annoyances).
In the absence of this constraint, the redundant lines marked "no longer needed"
could be removed from the following declarations in a body:
type a_rec; -- no longer needed
type a_rec_ptr is access a_rec;
type a_rec is record
next: a_rec_ptr;
end record;
procedure do_d; -- no longer needed
procedure do_c is
begin
do_d;
end;
procedure do_d is
begin
do_c;
end;
:But as I noted, this point is totally irrelevant to the discussion, since
:of course the spec appears "before" the body, so there are no ordering
:relationships imposed on the entities in the body that correspond to those
:in the spec in any case.
True.
Don. (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison au.com.csa.syd@donh
next prev parent reply other threads:[~1997-09-09 0:00 UTC|newest]
Thread overview: 185+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <01bcb389$24f579d0$1c10d30a@ntwneil>
1997-08-28 0:00 ` Interface/Implementation (was Re: Design by Contract) Tucker Taft
1997-08-29 0:00 ` Paul Johnson
1997-08-29 0:00 ` Jon S Anthony
[not found] ` <EFqDC8.342@ecf.toronto.edu>
1997-09-02 0:00 ` Samuel Mize
1997-09-03 0:00 ` Patrick Doyle
1997-09-03 0:00 ` Samuel Mize
1997-09-03 0:00 ` Paul Johnson
1997-09-04 0:00 ` Erik Ernst
1997-09-05 0:00 ` Robert Dewar
[not found] ` <EFyrH2.7z2@syd.csa.com.au>
1997-09-04 0:00 ` Joerg Rodemann
1997-09-05 0:00 ` Don Harrison
[not found] ` <340fdb9f.0@news.uni-ulm.de>
1997-09-06 0:00 ` Joachim Durchholz
1997-09-06 0:00 ` Joachim Durchholz
1997-09-04 0:00 ` W. Wesley Groleau x4923
1997-09-05 0:00 ` Don Harrison
1997-09-05 0:00 ` Jon S Anthony
1997-09-06 0:00 ` Fergus Henderson
1997-09-06 0:00 ` Jon S Anthony
1997-09-05 0:00 ` W. Wesley Groleau x4923
1997-09-06 0:00 ` Joachim Durchholz
1997-09-09 0:00 ` Robert Dewar
1997-09-09 0:00 ` Richard Kenner
1997-09-10 0:00 ` Tucker Taft
1997-09-10 0:00 ` Nick Leaton
1997-09-10 0:00 ` W. Wesley Groleau x4923
1997-09-11 0:00 ` Code ordering Steve Furlong
1997-09-12 0:00 ` Interface/Implementation (was Re: Design by Contract) Robert Dewar
1997-09-12 0:00 ` Nick Leaton
1997-09-10 0:00 ` Joachim Durchholz
1997-09-10 0:00 ` One pass compilation? W. Wesley Groleau x4923
1997-09-11 0:00 ` Interface/Implementation (was Re: Design by Contract) Robert Dewar
1997-09-08 0:00 ` Robert Dewar
1997-09-11 0:00 ` Don Harrison
1997-09-12 0:00 ` Robert Dewar
1997-09-08 0:00 ` Robert Dewar
1997-09-11 0:00 ` Don Harrison
1997-09-05 0:00 ` Jon S Anthony
1997-09-06 0:00 ` Patrick Doyle
1997-09-06 0:00 ` Jon S Anthony
1997-09-05 0:00 ` Patrick Doyle
1997-09-05 0:00 ` W. Wesley Groleau x4923
1997-09-06 0:00 ` Patrick Doyle
1997-09-05 0:00 ` Matthew Heaney
1997-09-06 0:00 ` Patrick Doyle
1997-09-06 0:00 ` Matthew Heaney
1997-09-07 0:00 ` Patrick Doyle
1997-09-07 0:00 ` Matthew Heaney
1997-09-10 0:00 ` Don Harrison
1997-09-10 0:00 ` Patrick Doyle
1997-09-16 0:00 ` Don Harrison
1997-09-18 0:00 ` Robert Dewar
1997-09-18 0:00 ` Shmuel (Seymour J.) Metz
1997-09-20 0:00 ` Robert Dewar
1997-09-10 0:00 ` Samuel Mize
1997-09-10 0:00 ` Samuel Mize
1997-09-11 0:00 ` Robert Dewar
1997-09-12 0:00 ` Samuel T. Harris
1997-09-12 0:00 ` Samuel Mize
1997-09-13 0:00 ` Tucker Taft
1997-09-17 0:00 ` Don Harrison
1997-09-18 0:00 ` Robert Dewar
1997-09-11 0:00 ` Don Harrison
1997-09-10 0:00 ` Tucker Taft
1997-09-10 0:00 ` Don Harrison
1997-09-12 0:00 ` Robert Dewar
1997-09-16 0:00 ` Don Harrison
1997-09-17 0:00 ` Robert Dewar
1997-09-10 0:00 ` Matthew Heaney
1997-09-10 0:00 ` Patrick Doyle
1997-09-12 0:00 ` Robert Dewar
1997-09-13 0:00 ` Patrick Doyle
1997-09-11 0:00 ` Lee Webber
1997-09-15 0:00 ` W. Wesley Groleau x4923
1997-09-12 0:00 ` Don Harrison
1997-09-10 0:00 ` Matthew Heaney
1997-09-11 0:00 ` Robert Dewar
1997-09-10 0:00 ` Robert Dewar
1997-09-10 0:00 ` Nick Leaton
1997-09-16 0:00 ` Frederic Guerin
1997-09-06 0:00 ` Matthew Heaney
1997-09-06 0:00 ` Joachim Durchholz
1997-09-06 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply)
1997-09-06 0:00 ` Jon S Anthony
1997-09-08 0:00 ` John G. Volan
1997-09-09 0:00 ` Paul Johnson
1997-09-09 0:00 ` Nick Leaton
1997-09-09 0:00 ` John G. Volan
1997-09-10 0:00 ` Nick Leaton
1997-09-10 0:00 ` Samuel Mize
[not found] ` <dewar.873826570@merv>
1997-09-09 0:00 ` Matthew Heaney
1997-09-11 0:00 ` Robert Dewar
1997-09-07 0:00 ` Robert Dewar
1997-09-08 0:00 ` Patrick Doyle
1997-09-09 0:00 ` Don Harrison [this message]
1997-09-09 0:00 ` W. Wesley Groleau x4923
1997-09-10 0:00 ` Robert Dewar
1997-09-11 0:00 ` Don Harrison
1997-09-12 0:00 ` Robert Dewar
1997-09-16 0:00 ` Don Harrison
1997-09-17 0:00 ` Robert Dewar
1997-09-01 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply)
1997-09-02 0:00 ` Nick Leaton
1997-09-03 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply)
1997-09-15 0:00 Marc Wachowitz
1997-09-16 0:00 ` Owen Fellows
-- strict thread matches above, loose matches on Subject: below --
1997-09-12 0:00 Marc Wachowitz
1997-09-12 0:00 ` Samuel T. Harris
1997-09-12 0:00 ` Jon S Anthony
1997-09-15 0:00 ` Samuel T. Harris
1997-09-16 0:00 ` Jon S Anthony
1997-09-12 0:00 ` Joachim Durchholz
1997-09-09 0:00 Marc Wachowitz
1997-09-15 0:00 ` Owen Fellows
1997-10-13 0:00 ` Bill Foote
1997-09-06 0:00 Ell
1997-09-06 0:00 ` Samuel Mize
[not found] <EForKz.FJ7@ecf.toronto.edu>
1997-09-01 0:00 ` Don Harrison
1997-09-02 0:00 ` Don Harrison
1997-08-07 0:00 Safety-critical development in Ada and Eiffel Ken Garlington
1997-08-12 0:00 ` Don Harrison
1997-08-25 0:00 ` Design by Contract Bertrand Meyer
[not found] ` <3402d123.0@news.uni-ulm.de>
1997-08-26 0:00 ` Nick Leaton
[not found] ` <3402e51d.0@news.uni-ulm.de>
[not found] ` <3402E8C9.3384D976@calfp.co.uk>
[not found] ` <dewar.872631036@merv>
[not found] ` <3403F668.F6B57D97@calfp.co.uk>
[not found] ` <34041331.0@news.uni-ulm.de>
[not found] ` <3404696D.4487EB71@eiffel.com>
1997-08-27 0:00 ` Interface/Implementation (was Re: Design by Contract) Bertrand Meyer
[not found] ` <34048FDC.13728473@eiffel.com>
1997-08-27 0:00 ` Bertrand Meyer
1997-08-28 0:00 ` Patrick Doyle
1997-08-28 0:00 ` W. Wesley Groleau x4923
1997-08-28 0:00 ` Jon S Anthony
1997-08-29 0:00 ` Robert Dewar
[not found] ` <EForsv.Fqo@ecf.toronto.edu>
[not found] ` <JSA.97Aug29191413@alexandria.organon.com>
[not found] ` <EFqDAG.2zn@ecf.toronto.edu>
1997-08-30 0:00 ` Jon S Anthony
1997-09-02 0:00 ` Don Harrison
1997-09-02 0:00 ` Jon S Anthony
1997-09-03 0:00 ` Don Harrison
[not found] ` <EFwuzD.BxE@ecf.toronto.edu>
1997-09-04 0:00 ` John G. Volan
1997-09-04 0:00 ` W. Wesley Groleau x4923
1997-09-05 0:00 ` Patrick Doyle
1997-09-05 0:00 ` W. Wesley Groleau x4923
1997-09-06 0:00 ` Patrick Doyle
1997-09-08 0:00 ` Paul Johnson
1997-09-06 0:00 ` Jon S Anthony
1997-09-08 0:00 ` Robert Dewar
1997-09-09 0:00 ` Robert S. White
1997-09-09 0:00 ` Patrick Doyle
1997-09-09 0:00 ` Matthew Heaney
1997-09-10 0:00 ` Patrick Doyle
1997-09-09 0:00 ` Paul Johnson
1997-09-11 0:00 ` Robert Dewar
1997-09-11 0:00 ` Veli-Pekka Nousiainen
1997-09-12 0:00 ` Paul Johnson
1997-09-14 0:00 ` Ken Garlington
1997-09-09 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply)
1997-09-10 0:00 ` John Viega
1997-09-10 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply)
1997-09-05 0:00 ` Patrick Doyle
1997-09-05 0:00 ` Franck Arnaud
1997-09-04 0:00 ` Don Harrison
1997-09-05 0:00 ` Patrick Doyle
1997-09-09 0:00 ` Don Harrison
1997-09-09 0:00 ` W. Wesley Groleau x4923
1997-09-10 0:00 ` Veli-Pekka Nousiainen
1997-09-10 0:00 ` Samuel Mize
1997-09-12 0:00 ` Don Harrison
1997-09-10 0:00 ` Patrick Doyle
1997-09-10 0:00 ` Joerg Rodemann
1997-09-10 0:00 ` Patrick Doyle
1997-09-11 0:00 ` Matt Austern
1997-09-12 0:00 ` Jon S Anthony
1997-09-13 0:00 ` Patrick Doyle
1997-09-10 0:00 ` Joachim Durchholz
1997-09-12 0:00 ` Joerg Rodemann
1997-09-11 0:00 ` Robert S. White
1997-09-11 0:00 ` Don Harrison
1997-09-12 0:00 ` Robert Dewar
1997-09-13 0:00 ` Patrick Doyle
1997-09-12 0:00 ` Jon S Anthony
1997-09-13 0:00 ` Patrick Doyle
1997-09-16 0:00 ` Brian Rogoff
1997-08-28 0:00 ` Tucker Taft
1997-08-28 0:00 ` W. Wesley Groleau x4923
1997-08-28 0:00 ` Jon S Anthony
1997-08-29 0:00 ` Suzanne Zampella
1997-08-29 0:00 ` Jon S Anthony
[not found] ` <EFnK8D.Lsv@ecf.toronto.edu>
1997-08-29 0:00 ` Jon S Anthony
1997-08-30 0:00 ` Patrick Doyle
1997-08-30 0:00 ` Jon S Anthony
1997-09-01 0:00 ` Patrick Doyle
[not found] ` <340E9BA2.32B3@rbgg252.rbg1.siemens.de>
1997-09-07 0:00 ` Robert Dewar
[not found] ` <3406A707.787D@dmu.ac.uk>
1997-08-29 0:00 ` Joerg Rodemann
1997-08-29 0:00 ` Ralph Paul
1997-09-01 0:00 ` Don Harrison
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox