Good Morning,
Philipp von Weitershausen wrote:
In the issue you write:
I can see two ways:
1. Extend the IAnnotations interface to grow the necessary
methods and support the existing use cases
2. Remove the ability from the existing attribute annotation
and re-write the code that uses it to avoid using __iter__
__contains__ and items.
Both are not acceptable, especially option #1. We can't just change
existing contracts as we see fit.
Right. However, I think it's possible to regard this is a bug in the
original contract. Regarding it as a bug might make it possible for us
to change the contract. I agree that we need to be careful about
changing them though.
Here's what I suggest: We create a new interface based on IAnnotations
that expresses __iter__ and __contains__::
class IIterableAnnotations(IAnnotations):
def __iter__():
pass
def __contains__():
pass
Hmm. Looks like an elegant solution to me. When I wrote those options
down, I thought that extending an interface wouldn't be too bad, but
you're right. Any changes to the API are equally hard to introduce.
However, I guess we should be able to integrate this back into the
IAnnotations. Is there a reason anyone will care about the distincation
of IAnnotations vs. IIterableAnnotations who doesn't know that we hadn't
had those methods originally?
If there is no reason for the distinction, it should go away, at least
long term. I know this comes down to evolving an interface which is
hard/impossible to do anyway.
Code that needs iteration or containment functionality can adapt to
IIterableAnnotations. Adapters that actually provide those methods can
register themselves as such (the attribute-annotations adapter will
surely be able to do that).
The issue also mentions .items(). Any feelings about that?
Christian
--
gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany
www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development
signature.asc
Description: OpenPGP digital signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com