[Zope3-dev] Allowing views to be registered for classes rather than interfaces.

[Phillip J. Eby]

At 07:54 PM 7/18/03 +0300, Steve Alexander wrote:

>>Conceptually speaking, to assert that a class (or object) implements an 
>>interface, is the same thing as saying that it may be adapted to that 
>>interface via a "null adapter".
>
>The identity adapter?

I guess if you think of adaptation as multiplication, then it would be the 
identity/unity adapter.  :)  If you think of it as addition, then it would 
be the zero (null) adapter.  :)


>>Thus, I disagree that explicit nonce interfaces are a "pure" design.  To 
>>me, the pure design would be allowing adaptation from anything to 
>>anything (as PyProtocols does).
>>Arguably, this is also more conceptually compatible with interfaces in 
>>other languages, where there is not nearly so sharp a line drawn between 
>>classes and interfaces as in Zope.
>
>Do you know enough about Zope 3 to be able to say what features Zope 3 
>interfaces have that PyProtocols lacks?

Do you mean interfaces, or the Z3CA?  As far as the interfaces *themselves* 
are concerned, the features they add over PyProtocols are metadata and 
validation capabilities.  The latest version of PyProtocols can adapt and 
decorate Zope 3 standard interfaces to add pretty much all of PyProtocols' 
other abilities, without interfering with the Zope-defined behaviors.

For the Z3CA, the main feature that PyProtocols lacks is placeful 
registries.  However, PyProtocols can emulate this by using "placeful 
variants" of an interface.  One advantage of this technique is that it 
eliminates the need to search multiple registries for an adapter (because 
registration is automatically "pushed" to the variants.)  The disadvantage 
would be loss of dynamic context ordering, but it's recently been discussed 
here that maybe having such dynamic paths isn't such a good thing, after all.

The main "unknown" that I know of, is the implications of persistence on 
interfaces.  PyProtocols interfaces store their own adapters, so this 
implies that a persistent interface would need to be able to pickle any 
registered adapters.  Also, they use the implementing classes as keys, so 
if a persistent interface references a class defined in a persistent 
module, that could be something of a GC issue.

Apart from that, I'd say the main thing I am ignorant of is schemas, and 
how closely they relate to this, assuming that they do.

Please understand that I'm not promoting Zope dump its interfaces or CA in 
favor of PyProtocols; just offering that some of these issues have been 
addressed therein, and that "borrowing" some of its solutions may be in 
order.  :)  The code is under PSF and ZPL, so feel free to hack away.