[Zope-Perl] Method binding

Jim Fulton jim@digicool.com
Wed, 18 Oct 2000 09:54:29 -0400


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