Philipp von Weitershausen wrote:
Grégoire Weber wrote:

while modeling the external API of an application I'd like to use the
tagged value feature of the interface implementation.

It seems to me that handling tagged values is implemented inconsequently.

It would be nice if tagging attributes and interfaces would look the
same as tagging methods:

in the interface definition:

   meth.tag = 'tagged' # interrestingly ``meth.setTaggedValue`` doesn't work


This is, for example, useful for setting the precondition on __setitem__
method defintions for containers::

  class IRecipeContainer(IContainer):
      def __setitem__(name, object):
          """Add a recipe"""
      __setitem__.precondition = ItemTypePrecondition(IRecipe)

Having to use setTaggedValue would be a lot less syntactic sugar for
nothing.

It's not for nothing. It's for separation of namespaces.
(Tagged values are a lot like annotations in that respect.)

Of course, the prefered way to express the above now is:

  zope.app.container.contstraints.contains(IRecipe)


API inconsistencies usually have no specific reasons other than
bitrotting, I guess.

Yeah, IOW, sounds like a bug.

I would say that a 'setTaggedValue' method is a bit unpythonic (it
actually feels quite Javaish).

This is a very old api, going way back before z3.


> I realize that the concept of tagged
values is well known from UML, that doesn't mean we can use pythonic
idioms for it though. I personally would prefer using the
__getitem__/__setitem__ protocol for this, but interfaces unfortunately
already use this for accessing interface members (e.g. IRecipe['name']).
I wish they would use the __getattr__ protocol (e.g. IRecipe.name).
Maybe it's not too late to change this, though it would be hard. It
would also make IInterface really tricky (what would
IInterface.implementedBy be?).

I don't think there is really a need to change this.  If I was going
to change this, I'd probably use the annotations approach.

Jim

--
Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to