>From: Michel Pelletier <[EMAIL PROTECTED]>
>Jim Fulton wrote:
>> 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 advocate more points than that, like being able to document python
>with python, no XML mixed in with a language, Py Meths working like
>other methods do, but yes that is one of them.
>My argument should be more flexible in regard to choice, a willing
>compromize is to switch the default binding of context and container,
>making 'self' the default for context and something else the default for
>> 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.
>Python methods are meant for through the web usability and programming
>ala the existing Zope model. 90% of your audience just scratched their
>> 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.
>this is how I feel python methods should be designed to be used.
>> 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.
>I think this is a weak argument, none of the built in Zope methods mean
>anything to the average user, they can't find them, click on them, edit
>them, or copy them to their own method to change and experiment with.
>> We have some methods that are designed to bound to an instance
>> (container, in your terminology)
>Python Method 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>
>This is because DTML binding is implicit, not because it's backward.
>This problem doesn't effect python methods because you allways bind a
>method in python when you call it. The question is how the initial
>method gets bound.
>> 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.
>I agree there must be control over binding, although your arguments
>above have not convinced me that Python Methods are doing it the right
>way, actually, it's convinced more than my argument, compromisingly of
>course, is more right.
>> 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.
>I'm with you so far with that.
>> 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.
>That's what I disagree with. I don't think you've given a strong
>corollary to standard python usage. The only strong argument you've
>given so far is the ZClass one, but 10 gives you 1 that's not the
>primary use case (it may be the one in Fburg). People are going to be
>defining these methods in Zope to make their lives easier, probably bad
>design and mad hacks and no structure, but that's how 90% of the world
>gets their work done and easing that burden is the usability task. You
>have not convinced me that:
>1. Something called a Python Method should not resemble a method
>definition in python.
>2. Something called a Method in Zope should not behave like the other
>Methods (meaning through the web objects) in Zope
>3. Common, *documented* well understood URL manipulations (context) are
>less important than (the less common) containment oriented design and
>Consider the following passage in the documentation:
> For example suppose you want to call a method named *viewFolder*
> one of your folders. Perhaps you have many different *viewFolder*
> methods in different locations. Zope figures out which one you
> by first looking in the folder that you are calling the method on.
> it can't find the method there it goes up one level and looks in
> folder's containing folder. If the method can't be found there it
> goes up another level. This process continues until Zope finds the
> method or gets to the root folder. If Zope can't find the method
> the root it gives up and raises and exception.
> Zope breaks the parts of the path up and walks along the object
> hierarchy looking for each part. This process is called *URL
> traversal*. For example, when you give Zope the URL
> *Zoo/LargeAnimals/hippo/feed'*. It starts at the root folder and
> looks for an object named *Zoo*. It then moves to the *Zoo*
> folder and looks for an object named *LargeAnimals*. It moves to
> the *LargeObjects* folder and looks for an object named
> *hippo*. It moves to the *hippo* object and looks for an object
> named *feed*. The *feed* method is found in the *Zoo* folder by
> a process called *acquisition*. Now Zope has reached the end of
> the URL. It calls the last object found, *feed*, on the second
> to last object found, the *hippo* object. This is how the *feed*
> method is bound to the *hippo* object.
>And further on:
> Suppose 'feedHippo.py' is a Python Method. How could you call the
> 'Diet/feed' method on the 'LargAnimals/Hippo' object from your
> Python Method. Here's how::
> In other words you simply access the object using the same
> acquisition path as you would use if calling it from the
> web. Likewise in Perl you could say::
> Using methods from other methods is very similar to calling
> methods from the web. The semantics differ slightly but the same
> acquisition rules apply.
>These paragraphs are just exceperts from two whole sections that try to,
>quite sucessfully acording to the feedback we've gotten, explain the
>method binding pattern in Zope. We give a real world application and
>justification in both sections on why this is useful and explain the
>concept in simple terms. Now, this needs to be re-explained, rewritten,
>and made overly complicated for what I feels are not very important
>reasons. Where are the applications and design patterns documented for
>your argument? Perhaps those could convince me if they justified it
>from the perspective of the beginner. I suggest you read over Chapter 7
>and weigh these descision from the eyes of a newbie.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -