Re: Separation of IF and Imp: process issue?

[mheaney@ni.net (Matthew Heaney)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3729 bytes --]



In article <5upe9k$7he@newshub.atmnet.net>, dnew@zloty.fv.com (Darren New)
wrote:


>(Hmmm... Nothing would actually tell the clients that they're invalid 
>any more, automatically.  I suppose the same is true of Ada, tho. Do your
>Ada tools warn you to go fix all your code that references packages
>whose interface has changed since you last editted them? If so, why would
>you think the same couldn't be done for Eiffel?)

I wasn't trying to disparage Eiffel (which I happen to like); I was trying
to explain to an Eiffel user the rationale for Ada's separation of
interface and implementation.

The point I was trying to make (actually, it was Tuck who explained it
better) concerns precisely the issue you alluded to: that changing the spec
can potentially break its clients.  The spec is a contract, and it can't be
just changed indiscriminantly.  The author of the spec has to go visit the
clients and ask if the change is OK; a negotiation must take place between
spec author and spec users.

The Ada model is that the specification is therefore a contract, to be kept
separate from the implementation.  The programmer of an implementation has
to assert that his body conforms to that contract.  The separation of
interface and implementation also allows the contract to be managed
independently of the implementation, using traditional configuration
management tools.

The Eiffel argument against this model is that it requires the programmer
to write the subprogram signitures twice; this is a fair enough criticism. 
However, if you ask an Ada programmer how he feels about this
"encumbrance," he'll tell you it isn't an encumbrance at all, and that he
actually likes the fact the interface and implemenation are in separate
files.

No one can argue with the philosophy that "a programmer shouldn't have to
write something twice, because if he does so he may make an error, so
there's inconsistancy."  But this is a weak argument against Ada's
separation of spec and body, as the compiler checks that that subprogram
signitures in the spec and body match.  

That this is "manual work better done automatically by a computer rather
than manually by a human programmer" is also a fair criticism, but again a
weak argument.  Many environments will generate the subprogram stubs
automatically, and besides, the signitures are small compared to the rest
of the body.  In any case, the writing of subprogram signitures consumes
only a tiny fraction of the programmer's time.  For example, when I'm
writing a unit, I'll write the spec, compile it, and then use a copy of the
spec as the starting point for the body.  (To be honest, though, I never
write an abstraction in strictly "spec then body" order.)

Eiffel programmers, here's some advice: choose your battles more carefully. 
If you argue against something that isn't that big an issue for the
programmers to whom the issue applies, then it tends to make all your other
(potentially good) arguments suspect.


>>The change affects only the Balking_Queue subclass - not the abstract
>>superclass.  That's why I'm not clear how freezing the spec of the root
>>type really solves anything.
>
>The balking queue is another class, in Eiffel, with its own spec,
>etc. I'm not sure I understand the question.  Freezing the spec of
>Queue solves the problem of changing Queue, not the problem of changing
>Balking_Queue.

I agree; that's the argument exactly.  How would freezing the spec of the
abstract superclass help you do change control on the subclass?  I don't
think that solves the problem of how to manage the specification of an
abstraction.

To get random signatures put text files into a folder called �Random
Signatures� into your Preferences folder.