Re: [Zope-dev] RFC: Python/Zope Interfaces
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 know the "design by contract" concept from Bertrand Meyer, the Eiffel developper. In Eiffel, essential parts of the contract, among others method prototype, pre- and post-conditions as well as invariants are build directly into the language. A documentation tool extracts these parts from the source to generate the interface, for people that are only interested in how to use the class/method. Programms can be executed in a way, that the various (executable) contract parts can be checked at runtime. *THIS* provides for quite a strong contract. I cannot see, why the separation of interface and implementation should make the contract stronger. I do see, however, that it makes it more likely to be broken by the implementation. It is a very good thing to have the specification very near to the implementation -- as a permanent guide to the implementor. It is even better, when big parts of the specification becomes part of the executable code (as is the case for Eiffel's pre- and post-conditions). If you want to prevent your implementors to change the interface specification, generate the interface for the implementation and compare against your master copy. In my view, it is better to have a somewhat "weaker" contract that is met by the partners than a "stronger" contract that is violated. Or, to say it differently, it is more essential the a system's documentation describes faithfully what is rather than what should be (but is not). Dieter
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 know the "design by contract" concept from Bertrand Meyer, the Eiffel developper.
In Eiffel, essential parts of the contract, among others method prototype, pre- and post-conditions as well as invariants are build directly into the language. A documentation tool extracts these parts from the source to generate the interface, for people that are only interested in how to use the class/method.
Programms can be executed in a way, that the various (executable) contract parts can be checked at runtime. *THIS* provides for quite a strong contract.
I cannot see, why the separation of interface and implementation should make the contract stronger. I do see, however, that it makes it more likely to be broken by the implementation.
The "contract" is a policy. The mechanisms of interfaces should not require that the policy be "strong" or "weak". This is up to the contractor. 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. What I said above was just a scenario, not necessarily any position I advocate. The current python interface proposal makes no statement on the strength of a contract. It sounds like you want your contracts to be strong, fine, but Python has no explict compile-time or run-time interface enforcement. The proposal in question is just trying to define how interfaces are defined, created, implemented, and used. Strong contractual enforcement is a minor, policy-specific decision.
It is a very good thing to have the specification very near to the implementation -- as a permanent guide to the implementor. It is even better, when big parts of the specification becomes part of the executable code (as is the case for Eiffel's pre- and post-conditions).
Maybe. I disagree in this case: this proposal states that interfaces are discoverable documentation, not language or policy enforcement. The less they can be tied to specific policies the more flexible they can be. Keep in mind, if you want run-time interface enforcement, you can *allways* add it with mxProxy or some other mechanism. If you *don't* want run-time interface enforcement and we made it a requirement, you'd be stuck. You can allways add, but you can rarely take away. -Michel
On Mon, 27 Nov 2000, Michel Pelletier wrote:
Dieter Maurer wrote:
It is a very good thing to have the specification very near to the implementation -- as a permanent guide to the implementor. It is even better, when big parts of the specification becomes part of the executable code (as is the case for Eiffel's pre- and post-conditions).
I'm not expert on eiffel or even interfaces, but my understanding having interface "specification very near to the implementation" is misleading, at best. The key thing is that there may be many implementations, all of which should be written to the same implementation - so you do not want the interface specification tied to any one of them. Ken klm@digicool.com
Ken Manheimer wrote:
I'm not expert on eiffel or even interfaces, but my understanding having interface "specification very near to the implementation" is misleading, at best. The key thing is that there may be many implementations, all of which should be written to the same implementation - so you do not want
Should that be 'same interface'?
the interface specification tied to any one of them.
This is a very good point! I'd be really interested in making something that supported the Catalog 'interface' but actually used the new MySQL full-text searching stuff to do the indexing/searching. However, until Catalog has a defined _interface_, I'm not even going to think about starting :-S Anyone know when that's likely to happen? cheers, Chris
Chris Withers wrote:
Ken Manheimer wrote:
I'm not expert on eiffel or even interfaces, but my understanding having interface "specification very near to the implementation" is misleading, at best. The key thing is that there may be many implementations, all of which should be written to the same implementation - so you do not want
Should that be 'same interface'?
the interface specification tied to any one of them.
This is a very good point!
I'd be really interested in making something that supported the Catalog 'interface' but actually used the new MySQL full-text searching stuff to do the indexing/searching.
However, until Catalog has a defined _interface_, I'm not even going to think about starting :-S
Anyone know when that's likely to happen?
A couple of years ago. (hehe - sorry, had to). The Z Search Interface is well defined (not well documented) and the Catalog is not the only object that implements it, so do ZSQL Methods and Z Network Adapters (which you've probably never heard of, they're buried in the CVS somewhere...). The 'Z Search Inteface' object is one tool in particular that uses it, perhaps you can in imply the interface from that since it is not documented. -Michel
Ken Manheimer writes:
Dieter Maurer wrote:
It is a very good thing to have the specification very near to the implementation -- as a permanent guide to the implementor. It is even better, when big parts of the specification becomes part of the executable code (as is the case for Eiffel's pre- and post-conditions).
I'm not expert on eiffel or even interfaces, but my understanding having interface "specification very near to the implementation" is misleading, at best. The key thing is that there may be many implementations, all of which should be written to the same implementation - so you do not want the interface specification tied to any one of them. What about *ALL* of them.
Source documentation is essential for high quality software. A major part of the documentation is what each programming entity is obliged to do by contract. Therefore, I would like this information to be near the implementation. Dieter
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".
Separation by itself does not make the contract stronger. Dieter
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
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. Good!
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. Good. 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. Dieter
Dieter Maurer wrote:
If you do change the implementation, then the specification can probably be changed at the same time.
IMHO, this is the wrong way round. If the interface doesn't cover what it needs to, update the interface and then make sure all the implementations are updated afterwards. cheers, Chris
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 know the "design by contract" concept from Bertrand Meyer, the Eiffel developper.
In Eiffel, essential parts of the contract, among others method prototype, pre- and post-conditions as well as invariants are build directly into the language. A documentation tool extracts these parts from the source to generate the interface, for people that are only interested in how to use the class/method.
Programms can be executed in a way, that the various (executable) contract parts can be checked at runtime. *THIS* provides for quite a strong contract.
I cannot see, why the separation of interface and implementation should make the contract stronger.
The interface *is* the contract. If someone builds a house for me, I don't want the house to *be* the contract. I want the house to adhere to the contract. Interface/contract and implementation are two qualitatively different things.
I do see, however, that it makes it more likely to be broken by the implementation.
I don't think it makes it more or less likely. Of course, if the "interface" is always derived from the implemenation then the two will be consistent, but this is not terribly useful.
It is a very good thing to have the specification very near to the implementation -- as a permanent guide to the implementor.
Firtunately, modern displays allow multiple side-by-side windows. ;)
It is even better, when big parts of the specification becomes part of the executable code (as is the case for Eiffel's pre- and post-conditions).
If you want to prevent your implementors to change the interface specification, generate the interface for the implementation and compare against your master copy.
In my view, it is better to have a somewhat "weaker" contract that is met by the partners than a "stronger" contract that is violated.
We disagree then. A weak interface that is satisfied by definition is nearly useless to me.
Or, to say it differently, it is more essential the a system's documentation describes faithfully what is rather than what should be (but is not).
I disagree alot. I'd rather have clear documentation of intended behavior, rather than have the documentation change based on implementation decisions. Note also that most classes implement multiple interfaces. Generating interfaces from classes trends to yield bloated non-cohesive interfaces. Similarly, most interesting interfaces are implemented by multiple classes, so nearness to implementation is not really meaningful. Please note that these points were argued extensively on the Python types-sig a couple of years ago. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org
Jim Fulton writes:
Dieter Maurer wrote:
I cannot see, why the separation of interface and implementation should make the contract stronger.
The interface *is* the contract. If someone builds a house for me, I don't want the house to *be* the contract. I want the house to adhere to the contract. Interface/contract and implementation are two qualitatively different things. But this does not imply, that the contract becomes stronger, when interface and implementation are separated. Packaging issues do not change the contract.
I see however, that you usually will (should) start with a specification (the interface is part of it) and then provide an implementation (or more than one) for it.
In my view, it is better to have a somewhat "weaker" contract that is met by the partners than a "stronger" contract that is violated.
We disagree then. A weak interface that is satisfied by definition is nearly useless to me. If an implementation has nothing to do with its specification, then either the implementation or its specification is useless, at least in relation to one another.
But, you note, that I did not speak about "a weak interface that is satisfied by definition" but about a "somewhat weaker contract that is met by the partners compared to a somewhat stronger contract but violated contract".
Or, to say it differently, it is more essential the a system's documentation describes faithfully what is rather than what should be (but is not).
I disagree alot. I'd rather have clear documentation of intended behavior, rather than have the documentation change based on implementation decisions. If the implementation decisions are essential: e.g. linear versus logarithmic time complexity, I would like to have that stated in the documentation.
Note also that most classes implement multiple interfaces. Generating interfaces from classes trends to yield bloated non-cohesive interfaces. I may agree with this. Though some configuration for the generation process may help to reduce the danger.
Similarly, most interesting interfaces are implemented by multiple classes, so nearness to implementation is not really meaningful. It helps the implementation to adhere to the contract.
Please note that these points were argued extensively on the Python types-sig a couple of years ago. SIG archives tend to be non-searchable. I, probably, will not dig in to summarize the results. Even, if I do, this would be no garantee that I would be convinced.
Let me stress my point of view. Maybe, we are not too far away from one another: * I like clear specifications (as you do) * The specification has more value, when its implementations adhere to it (you probably will agree). * A documentation about an existing system is more valuable, when it states what is rather than what should be (here we may disagree). I usually start by studying the documentation. If it descibes what is, then I will recognize early what does not fit my requirements and can work around it. If it describes what should be, I will determine the deficiencies much later in my projects, modifications are much more difficult and expensive. * Having the specification near the implementation helps the implementors to adhere to it, especially with long maintenance periods. (Here we may disagree). I believe in the value of well documented source, in literate programming. Dieter
Dieter Maurer wrote:
(snip)
Let me stress my point of view. Maybe, we are not too far away from one another:
* I like clear specifications (as you do)
Yup.
* The specification has more value, when its implementations adhere to it (you probably will agree).
Well, not quite. If you use documentation of an interface to figure out how to use an existing implementation, then I agree that, for that purpose, an interface that documents the implementation accurately is valuable. OTOH, if the implementation is doing the wrong thing, an interface that documents doing the right thing is more valuable than an interface that documents the wrong thing. Given an interface that documents the right behavior, all I have to do is fix the implementation, which is easy. If both the interface and the implementation are wrong, then I not only have to fix the implementation *and* the interface, but, much worse, I have to fix all the client implementations that were written to the wrong interface.
* A documentation about an existing system is more valuable, when it states what is rather than what should be (here we may disagree).
It depends on the goal of the person using the documentation.
I usually start by studying the documentation. If it descibes what is, then I will recognize early what does not fit my requirements and can work around it. If it describes what should be, I will determine the deficiencies much later in my projects, modifications are much more difficult and expensive.
Or you could get (or help, as you often do, thanks) the author to fix the broken implementation.
* Having the specification near the implementation helps the implementors to adhere to it, especially with long maintenance periods. (Here we may disagree).
Yes, we disagree.
I believe in the value of well documented source, in literate programming.
I agree with the value of well documented interfaces *and* well documented implementation, source. I see alot of value for documenting the implementation in the source. I see *some* value of seeing the interface when writing and maintaining the source. I'm really happier seeing a separate specification. Perhaps this is a matter of taste. I wouldn't relish duplicating interface documentation in all of the implementations that implement it and trying to keep them consistent. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org
Jim Fulton wrote:
It is a very good thing to have the specification very near to the implementation -- as a permanent guide to the implementor.
Firtunately, modern displays allow multiple side-by-side windows. ;)
G400, two displays :-)
It is even better, when big parts of the specification becomes part of the executable code (as is the case for Eiffel's pre- and post-conditions).
:-(( I'd much prefer smaller lightweight interfaces with as little 'code' in them as possible...
Or, to say it differently, it is more essential the a system's documentation describes faithfully what is rather than what should be (but is not).
I disagree alot. I'd rather have clear documentation of intended behavior, rather than have the documentation change based on implementation decisions.
Yeah! ZSearch (thanks Michel, I did know about it but didn't express my point very well ;-) seems like a good example of this to me. The _interface_ deosn't seem to exist, just several implementations and no actual documentation. I wonder if the implementations all have the same functionality? They would if the interface was a contract...
Please note that these points were argued extensively on the Python types-sig a couple of years ago.
What was the outcome? Michel wrote:
However, until Catalog has a defined _interface_, I'm not even going to think about starting :-S
Anyone know when that's likely to happen?
A couple of years ago. (hehe - sorry, had to).
Well, sorry to correct you, but there isn't an _interface_, or at least one that's published.
The Z Search Interface is well defined (not well documented)
ie: there isn't an interface, there's just similar (I bet they're not identical) implementations in ZSearch, Catalog, ZSQL and ZNetwork (whatever that is ;-)
The 'Z Search Inteface' object is one tool in particular that uses it, perhaps you can in imply the interface from that since it is not documented.
As I said earlier, I totally agree with Jim that a weak interface like this isn't a lot of use. What happens next time someone tweaks the catalog and changes the functionality? Does that mean the interface has changed? How can all the seperate implementations keep up? I actually tried to make Squishdot implement the Z Search Interface when I moved to using the catalog, but it appeared at the time that ZCatalog didn't actually work properly with Z Search anyway. All of which kindof illustrates my point :-S The main thing for me is that the implementation is documented somewhere, which it isn't. Of course, it'd be much better if it was a proper interface as is being discussed here. Mindyou, it'd also be great if python had native interface support. What does Guido think about that? cheers, Chris :-)
Chris Withers wrote:
Jim Fulton wrote:
(snip)
Please note that these points were argued extensively on the Python types-sig a couple of years ago.
What was the outcome?
They all agreed to stop arguing with me. ;) Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org
participants (5)
-
Chris Withers -
Dieter Maurer -
Jim Fulton -
Ken Manheimer -
Michel Pelletier