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

[Mike C. Fletcher]

Steve Alexander wrote:

> Mike C. Fletcher wrote:
>
>> Wondering if anyone can point me at where in Zope3 I can find the 
>> Interface definitions for the various "simple" types:
>
...

> 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).

...

> You probably don't want to say that, in this case.
>
> But, see the IAnnotatable / IAnnotations interfaces in Zope 3 for an 
> example of this kind of pattern. 


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()

Then register strings and unicode objects as 
supporting IWordIterableString, and WordIterationStringAdapter as 
adapting IWordIterableString to IWordIteration.  The difference from 
what I was planning being the use of the IWordIterable "abstract-marker" 
base-interface to allow for lookup of the "abstract-marker" interface 
among multiple possible "concrete-marker" interfaces.

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?

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?  That is, there is a better way to 
define that (in the example above), str and unicode can be made to 
implement IWordIteration.  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).

Thanks for the help,
Mike