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.


Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to