Dieter Maurer wrote:
- It's an explicit declaration of support
As is the definition of "__of__".
Well, not in a formal sense. I could have some non-Zope python object
that I wanted to register as a local utility (to override a global one,
say) that could have __of__() for some other reason.
IAcquirer is an explicit, formalised statement of support for some
particular behaviour.
I doubt it matters in this case (I'd guess __of__() is not a very common
method name outside Zope, and this would be pretty localised code), but
in general, having code be conditional on hasattr() something can lead
to spaghetti code and unintended side effects.
- It may not be desirable to wrap everything that *could* be wrapped.
Could you explain?
In the Zope 2 world, non acquisition wrapped objects behave very strange
(as indicated in an earlier message).
Do you want to introduce special cases only that you can use Zope 3 magic?
It's pretty pointless to argue aesthetics, but I wanted to point out
what was the more accepted Zope 3 pattern (in my understanding and
opinion), i.e. relying on a formalised definition of some behaviour
rather than the implication that if something has a particular method it
must be what you think it is and must want a particular type of behaviour.
What if the method wasn't __of__() but get_size() or something in a
different context?
Also, I think it's perfectly reasonable that some local utilities, even
in a Zope 2 context, will not be acquisition wrapped. They may just be
local overrides of global ones, for instance, or local utilities to gain
persistence, but not for any other reason.
Of course, if you want things to behave in a Zope 2 like way
(containment by acquisition, security by acquisition, role manager
behaviour, whatever else) then you also want to aq wrapped in a Zope 2
like way.
Martin
_______________________________________________
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
