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

[Steve Alexander]

>> Maybe you'd like to write a proposal about providing suitable 
>> interfaces for a range of builtin types?
> 
> Hmm, probably just write them myself and see if anyone's interested in 
> the results.  Proposing something seems silly when I'd have to be the 
> one doing the work anyway. (Since no-one else has felt the need for them 
> to date).

One of the goals of my and Jim's "BetterInterfaceImplements" proposal is:

     * Make it possible to declare interfaces for built-in types.

http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/BetterInterfaceImplements

This goal is important for me. I already started the job off with 
interfaces for Exception classes. Those were easy and straightforward.

I wanted to make an adapter for unicode string objects in a project a 
few of weeks ago. I couldn't do that, because the unicode class doesn't 
implement an interface. That was what prompted me to start the 
aforementioned proposal.

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.

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, to see if I understand the prefered approach for what I'd 
> described (based on IAnnotatable) in a concrete (if hypothetical) 
> situation:
> 
> class IWordIteration( Interface ):
>    """The target interface that the application would care about"""
>    def iterWords( ):
>        """Provide an interable for all words in object"""
> 
> class IWordIterable( Interface ):
>    """Abstract marker interface declaring that item can be iterated as 
> words"""
> 
> class IWordIterableString( IWordIterable ):
>    """Particular interface for a string-like object which is iterable"""
>    def split( self, marker=None, count=None):
>        """split the word on word-boundaries (or whatever)"""
> 
> class WordIterationStringAdapter:
>    """Adapt an IWordIterableString-interfaced object to an 
> IWordIteration interface"""
>    def iterWords( self ):
>        """Get the client string as a set of words (sample, real-world 
> would be far more complex)"""
>        # how does the adapter get the pointer to the adapted object?
>        return self.value.split()

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


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.


> I can see how that's good from a purity standpoint (especially for 
> introspection), but from a practical standpoint, you never actually care 
> about the IWordIterable interface-types.  You would always ask for 
> IWordIteration on the object (since you don't care how it's 
> implemented), and get back the concrete adapter class (which only works 
> for the concrete marker interface).  Is the abstract marker class is 
> just extra bookkeeping?  Is there something I'm missing that makes it 
> more useful than it seems?

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.


> Anyway, if I'm reading correctly, you're saying that for 
> primitive/untouchable types one shouldn't be doing this kind of 
> interface adaptation regardless?

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)


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.


> I've read through the exceptions code again, 
> but it doesn't seem to be adding new interfaces to the exceptions, that 
> is, there's no new functionality defined (i.e. there's no adapters which 
> let you treat an IIOError as an IVirtualFileSystemIOError or the like).

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