On Tue, 28 Nov 2000, Dieter Maurer wrote:
> Michel Pelletier writes:
> > Dieter Maurer wrote:
> > > Michel Pelletier writes:
> > > > Also, defining the interface seperately keep the two things apart,
> > > > impementation and interface, and doesn't allow you to sneak in a new
> > > > method unless you also sneak it into the interface, thus making a
> > > > stronger "contract" with the user.
> > > I am a bit astonished by this statement:
> > > ....
> > ....
> > I'm not sure if you are making these statement because you
> > disagree with the current proposal or because you disagree with what I
> > said above.
> I disagree with the "separating implementation and interface
> makes for a stronger contract".
The separation need not mean that the specification is hard to access from
the implementations, either for documentation or for runtime enforcement.
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.
The principle is that an interface should be a discrete entity in its own
right, not subject to dis-integration for the sake of different
implementations. Tieing an interface specification to the implementations
can mean that separate *copies* of the specification drift.
I think you're asking for something internally contradictory, and not
seeing that - but, as i said in my first comment in this thread, i'm not
expert, and may be misinterpreting what you're asking.
> Separation by itself does not make the contract stronger.
If it preserves integrity, it does.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -