[Zope-dev] Re: [z3-five] relocating Zope 2 core interfaces - a proposal

[Philipp von Weitershausen]

yuppie wrote:
>>> Current State
>>> =============
>>>
>>> Five (now part of Zope 2.8) ships with one big interfaces.py file 
>>> that contains z3 interfaces for Zope 2 core classes. (There are also 
>>> some five specific interfaces in that file, but they are not subject 
>>> of this proposal.)
>>>
>>> interfaces.zcml states that Zope 2 implements these interfaces, but 
>>> there are no tests to verify that and in fact many of these 
>>> interfaces are broken in Five 1.0. (Yesterday I checked in some fixes 
>>> to the Five trunk.)
>>
>> Note that they also need to be in the 1.0 branch, if this is to be in 
>> Zope 2.8.
> 
> <sarcasm>Maybe it's better the interfaces are broken. That makes sure 
> people don't use them extensively and might give us a chance to relocate 
> them at a later point.</sarcasm>

Seriously, you should merge your r11978 to the Five-1.0 branch.0

>>> I grepped through CMFonFive, SilvaDocBook and SilvaFlexibleXML: None 
>>> of them use these interfaces.
>>
>> I think there's some code inside the Five tests that might use them. 
>> There's also a chance someone else is using them, but admittedly the 
>> risk of breaking something doesn't seem too big. This does deserve to 
>> be called 1.1 though if we're breaking APIs (this would then derive 
>> from the 1.0 branch, not the Five trunk).
> 
> Ok.

I don't think we need to break backward compatability. We would just 
need to deprecate the Five.interfaces location.

Basically, the goals are:

* The solution needs to work with Zope 2.7
* Preferrably, the interface import spelling should be equal on both
   systems (which means a monkey on 2.7 is probably inevitable).
* On 2.8 we want to have definitions of the z3-style interfaces in the
   Zope tree.
* Five.interfaces and OFS.interfaces.*, etc. need to contain
   the exact *same* interfaces (same, not equal) on both systems at all
   times.
* Five.interfaces should be deprecated as an import location in the long
   term.

>>> Proposed Solution
>>> =================
>>>
>>> 1.) Adding ZCML that bridges existing z2 interfaces into the 
>>> 'interfaces' module of their package. [Zope 2.8.0]
>>>
>>> 2.) Copying z3 interfaces from Five.interfaces to the 'interfaces' 
>>> module of the corresponding package. Marking those in Five as Zope 
>>> 2.7 backwards compatibility cruft. [Zope 2.8.0]
>>
>>> 3.) Doing the same for Zope 2.7 with monkey patching code. [Five 1.0+]
>>
>> I don't understand this step; what are you proposing?
> 
> It might be better to use the new locations also for Zope 2.7. But the 
> interfaces don't exist in Zope 2.7, so we would have to inject them into 
> Zope 2.7.

Yup. In Zope 2.7, the OFS.interfaces, etc. modules would have to be 
injected and be filled with the definitions from Five.interfaces. This 
is why Five.interfaces needs to be kept around anyway. It would probably 
be a sharade to Five._interfaces which is only imported on demand...

>>> 4.) Making interfaces.zcml point to the new locations. [Five 1.0+]
>>
>> While in Zope 2.8, we could add 'implements' in the Zope 2 code 
>> directly, we don't need to do this from ZCML anymore.
> 
> As you state below, there might be issues with mixing five:implements 
> and implements(). But if there are no issues, I agree that using 
> implements() would be better.

five:implements (which is equal to using zope.interface.classImplements) 
and implements() can be mixed. The class will in the end implement both 
definitions.

Philipp