[Zope-dev] Zope 2.8, Five and Interfaces

[Philipp von Weitershausen]

Tres Seaver wrote:
>>>I had a closer look at Zope 2.8's Five and I'm concerned about the
>>>fact that Five ships with redundant interface definitions:
>>>
>>>- redundant code is always a problem because it's hard to keep things
>>>in sync
>>>
>>>- the fact that Five is maintained in a different repository and
>>>should work with different Zope versions makes it almost impossible to
>>>change Zope interfaces in a consistent way
>>>
>>>So my questions are:
>>>
>>>1.) Why are interfaces that are available as Zope 2 interfaces
>>>duplicated in Five/interfaces.py instead of bridged?
>>
>>Partially I suspect this reason is historical -- the Zope 2 interfaces
>>were created by Philipp von Weitershausen before Tres implemented the
>>bridging functionality.

Correct.

>>>2.) Could we move the interfaces that are currently not available as
>>>Zope 2 interfaces to the corresponding packages in Zope 2.8, using
>>>Five/interfaces.py just as an fallback for Zope 2.7 and old Five
>>>products?
> 
> Maybe we need to spell out what the fallback would look like more clearly.
> 
> 
>>>If people agree that this is problem, I'd volunteer to help resolving it.
>>
>>It sounds like a reasonable idea, but it does introduce complications.
>>This does mean we need a separate version of Five for merging into Zope
>>2.8. Another potential problem is that some Five-based code is also
>>likely to stop working as the interface will change location (I'm not
>>sure what bridge does in this respect; does it create a new location for
>>the bridged interface?).
> 
> 
> The bridging code fabricates a new Z3 interface and bashes it into
> whatever module the directive specifies, so we could keep the same
> dotted names as the current interfaces.

Right. Here's what we could do:

1. Copy Five's interface definitions over to Zope 2.8 (mostly to 
OFS.interfaces, I guess) where they are added as Zope 2 interfaces

2. Keep Five's (redudant) interface definitions. They can stay at their 
status quo (status Zope 2.7, that is).

3. Add <five:bridge /> calls for every interface so that Five's 
interfaces are automatically kept up-to-date with the Zope 2.8 ones. The 
bridges would override the ones defined in the module, potentially 
updating with newer definitions. The only thing that we need to take 
care of is fallback for Zope 2.7 where the Zope 2 interfaces don't exist 
yet.

If you want to do this, yuppie, feel free to do it. I would even be ok 
for this to be done for the 1.0 branch, provided you also add it on the 
trunk.

>>If the interfaces change location due to
>>bridging, this also means Five + 2.7 code would be incompatible with
>>Zope 2.8 code that makes use of Five.
>>
>>I'm a bit worried about doing it now as it will take time and testing
>>effort, then again, if we are to do it, it would be better to start
>>moving things around before we release Zope 2.8..
> 
> +1.  I have an intent (but no time so far) to make the equivalent change
> for CMFonFive, as well.

Cool.

Philipp