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. Ken klm@digicool.com