Martin Aspeli wrote at 2007-1-9 20:48 +0000: > .... >>> - 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.
Theoretically, you might be right -- but not practically in the "ExtensionClass" based environment of Zope 2. There you have: if an object has an "__of__" it is used for context wrapping -- as soon at it happens to be accessed as attribute of an "ExtensionClass" instance. In this environment, it is more homogenous and natural to just wrap with "__of__" when it is present than looking for an additional marker interface. > ... >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)... More precisely, "__of__" has special (documented) meaning for "ExtensionClass". > .... >>> - It may not be desirable to wrap everything that *could* be wrapped. > ... >What if the method wasn't __of__() but get_size() or something in a >different context? I think, I would not have argued about automatic "get_size" wrapping -- unless it were so common as "ExtensionClass"'s "__of__" wrapping. -- Dieter _______________________________________________ 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
