[Zope-dev] Method binding

[Chris Withers]

Maybe the Zope-Dev guys have comments on this....

> >From: Jim Fulton <jim@digicool.com>
> >
> >Michel,
> >
> >You have advocated that methods should always be bound to the objects they
> >are accessed in. You argue that there should be no choice in the matter.
> >
> >I have to disagree strongly. I'll try to explain why.
> >
> >In Python, methods are bound to instances.  Methods are part
> >of an instance's core behavior. They are specific to the kind
> >of thing the instance is. In my words, methods are part of
> >the genetic makeup of an object.
> >
> >In Zope, we allow some methods to be bound to their context.
> >This is done in a number of ways and is sometimes very useful.
> >We have methods, like standard_html_header, which are designed
> >to be used in different contexts.
> >
> >We have other methods, like manage_edit that are designed to
> >work on specific instances. It would be an egregious error
> >if this method was acquired and applied to it's context.
> >
> >We have some methods that are designed to bound to an instance
> >(container, in your terminology) but that, because they are written in
> >DTML, can be bound to other objects. This can cause significant problems.
> >For example, methods defined in ZClasses almost always want to be
> >bound to ZClass instances, not to other arbitrary objects.
> >
> ><aside>There's a bonus problem with DTML Methods. When
> >a DTML Method is invoked from another DTML Method, it
> >is bound to neither the object it was accessed in or
> >to the object it came from. It is bound to the calling
> >namespace. It turns out that this is a useful behavior
> >if the DTML Method is designed to be used as a "subtemplate".
> ></aside>
> >
> >There is no one "right" way to bind a method. There are good
> >reasons to sometimes bind a method to it's context and
> >sometimes bind a method to it's container (ie instance).
> >There are even sometimes reasons to bind a method to a
> >calling namespace.
> >
> >The principle of least surprise doesn't help here, because
> >methods defined in Python classes don't behave the way
> >methods defined through the web do currently.
> >
> >We *need* control over binding, as well as reasonable defaults.
> >
> >If we can agree that we need binding control, the question
> >arises as to some details and default names.
> >
> >Should it be possible to do more than one binding at a time,
> >using multiple names?  If not, then I'd agree that the name
> >'self' should be used for either the context or container binding.
> >If both bindings are allowed at the same time, then 'self' should
> >refer to container binding to be consistent with standard Python
> >usage and some name like 'context' should be used (by default)
> >for contextual binding.
> >
> >Jim