Ken Manheimer writes:
 > The separation need not mean that the specification is hard to access from
 > the implementations, either for documentation or for runtime enforcement.  

But, objection will come later.

 > However, it *does* run contrary to the literate programming notion of
 > weaving together the description of software with the code.  When you have
 > multiple implementations that satisfy an interface, having a copy of the
 > interface spec with each implementation can lead to the drift described
 > above.  If you *want* discrete interface definitions with integrity across
 > implementations, you have to avoid this multiple, potentially conflicting
 > copies of the specification.

What I really want is that the implementation fulfills its contract!

If you change the specification but do not adapt some implementations,
then it is essential, that the implementation somehow tells,
which specification it implements.
One way to achieve this, it to have the specification integrated
(with some tool to extract it easily as e.g. in Eiffel).
Of cause, there are other ways to achieve this -- such as
efficient linking to the specification and careful versioning
of the specification documents.

If you do change the implementation, then the specification
can probably be changed at the same time.

I should stress, that I do not necessary call for a physical
copy of the specification/interface to be present
in the implementation. An unambigous and correct reference,
preferably interpretable by documentation generators,
should do as well.

 > I think you're asking for something internally contradictory, and not
 > seeing that.
If I do, indeed, I do not see it.

Jim gave the example:

  If someone builds him a house, he wants a contract that
  lays out the obligations. The house builder should
  fulfill this contract.


When I buy a house, I expect from the vendor a description,
what features the house *REALLY HAS* and not what
features the vendor would like the house to have.
Based on this description, I will decided whether or not
I will buy.

That's probably the difference between the specification
(created before the implementation starts and used
as a guideline for it) and the documentation (that describes
the concrete instance). Ideally, both are identical.
In practice, there are often discrepancies.


Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to