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.

Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to