[Zope3-dev] "common" or "basic" interface types?

[Mike C. Fletcher]

Steve Alexander wrote:
...

> I think the issue of interfaces for builtin types is important. I'd 
> like to see them provided as standard in the zope.interface package. 
> There are issues about how functionality and obligations are broken 
> down into different interfaces, which should be thought about and 
> written down and discussed. I don't think these things are obvious 
> right now. 

I assume you're talking about high-level interfaces, such as "keyed 
mapping", where the inclusion or exclusion of particular functionality 
within the interface would be dependent on the "abstract definition" of 
that interface.  I'm currently limiting myself to very low level interfaces.

> If you or someone else doesn't write a proposal, then I will eventually.
> I'm busy with other zope things right now, so I won't get around to it 
> for a while. I think this needs a proposal before it becomes a part of 
> zope. 

Okay, I'm a patient man ;) .

> An adapter has an __init__ method where it saves the context (the 
> object it is adapting) into an instance variable.
>
>   def __init__(self, context):
>       self.context = context

Wow, you'd think I would have seen that at some point in time.  Sheesh.

> Basically, that's the pattern. I would choose different names for 
> IWordIteration and IWordIterable, because your implementation doesn't 
> split into words, it splits on whitespace or some other marker, and 
> because 'iterable' already means something subtly different in python. 

In fact, I was intending to do a true iteration sample implementation, 
but got lazy somewhere in the middle of writing it :) , given that no 
one was actually going to use it.

> Is it important for annotations in zope because we often want to make 
> a view or adapter available on an object that is annotatable.
> The view or adapter works with an object's annotations.
> We don't want to register the view or adapter for all objects, just 
> for those that support annotations. 

Good point, noted for future reference.

> I don't think there needs to be a separate class of 'untouchable' types.
>
>
>> That is, there is a better way to define that (in the example above), 
>> str and unicode can be made to implement IWordIteration.
>
>
> Once the BetterInterfaceImplements proposal is realized, you will be 
> able to say:
>
>   classImplements(str, IWordIteration)
>   classImplements(unicode, IWordIteration)

Which seems to me to be describing the process for dealing with 
"untouchable" types?  That is, types where you cannot alter the type 
definition itself.  There are all sorts of instances I can think of 
where such types exist.  And this seems like a fine approach to 
annotating them.

> I think the proposal I suggested you write is needed so that zope can 
> come with a set of useful interfaces for builtin types. If that is so, 
> there needs to be some consensus on division of responsibility among 
> those interfaces, and the naming of the interfaces.

Well, given that consensus is much easier to build among those who are 
of like need, I will let the Zope peoples come to their consensus.  I 
don't really know what higher-level interfaces would be useful to the 
Zope crowd (it seems every time I touch Zope I just wind up writing 
low-level code, I never actually use the thing as its "intended" to be 
used :) .

> There are no adapters for that kind of thing. There could be such, but 
> I don't think anyone has needed them yet.
>
> There is new functionality defined for exceptions in the form of views 
> on exceptions. I am using these heavily in my own Zope 3 project. They 
> also appear in the Zope 3 source in CVS:
>
>   src/zope/app/browser/exception
>   src/zope/app/browser/skins/debug
>
> -- 
> Steve Alexander

Enjoy,
Mike

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/