On Tue, 2008-07-15 at 18:56 -0400, Benji York wrote:
> On Tue, Jul 15, 2008 at 6:31 PM, Tim Cook <[EMAIL PROTECTED]> wrote:
> >> Note: classes *implement* interfaces, their instances *provide* them.
> >
> > ... and I am still confused about a use case for classProvides.
> When one says that a class *provides* an interface they're saying that
> instances of that class *implements* the interface.
> On the other hand, lets say you had an IFooFactory interface that only
> required that objects *providing* it be callable.  In that case a class
> Foo itself can *provide* the interface (because the class is callable).
> Make sense?

Hmmm, not really.  I tend to be VERY applied so how about an example
from Zope?

class Maildir(object):
    """See `zope.sendmail.interfaces.IMaildir`"""


class IMaildirFactory(Interface):

    def __call__(dirname, create=False):
        """Opens a `Maildir` folder at a given filesystem path.


class IMaildir(Interface):
    """Read/write access to `Maildir` folders.

    See http://www.qmail.org/man/man5/maildir.html for detailed format

    def __iter__():
        """Returns an iterator over the pathnames of messages in this

    def newMessage():
        """Creates a new message in the `maildir`.

Now why wouldn't IMaildir just not inherit from IMaildirFactory instead
of from Interface?  If it did; what would be the effect of the
difference(s) in approach to the rest of the application?



Join the OSHIP project.  It is the standards based, open source
healthcare application platform in Python.
Home page: https://launchpad.net/oship/ 
Wiki: http://www.openehr.org/wiki/display/dev/Python+developer%27s+page 

Attachment: signature.asc
Description: This is a digitally signed message part

Zope3-users mailing list

Reply via email to