[Zope-dev] MethodGeddon

Shane Hathaway shane@digicool.com
Mon, 31 Jul 2000 14:15:24 -0400


Chris Withers wrote:
> 
> http://www.zope.org/Wikis/zope-dev/MethodGeddon
> 
> Just been reading about this and I was wondering how is coming along...

After more pondering I decided to throw out the idea for typed
arguments.  I was trying to solve a difficult problem with a
roundabout, and in the end more difficult solution.

> Is it in the fishbowl under another name or should it be in the
> fishbowl?

It would actually fall under the the "Current Projects" section.

http://dev.zope.org/Wikis/DevSite/Projects/PythonMethods/MethodObjectInterface

Alright, I didn't put it my comments in exactly the right place, but
it's close enough. :-)

> Shane, would the argument list be a management tab for methods?
> That sounds cool to me :-)

What I have done instead (and this is exactly the way Jim envisioned it
months ago) is added a "Bindings" tab to Python methods.  You just fill
in the names to be populated with an object's container, its context,
itself, the DTML namespace, and (this just in :-) the traversal
subpath.  Then I did the same thing with External Methods and combined
them into one product.  Unless my changes are vetoed, in the future you
won't be adding "External Methods" and "Python Methods" anymore, you'll
be adding "Python Method (Internal)" and "Python Method (External)"
instead.

I've checked it all into CVS but I'm not sure it's available to the
public.  Perhaps it should be; lobby Ken or Brian.  It's the module
Packages/Products/PythonMethod.

> I reckon 'self' should always be the equivalent of the python 'self' or
> not exist to avoid confusion. I guess that means it wouldn't get used
> much since it would be the actual method-object (and I thought that was
> an oxymoron ;-) but with the possibility opf things like __render__ and
> __call__, who knows...

Jim solved this confusion by letting you invent your own names, then we
made it easier to use by providing "recommended names": container,
self, m_self (the method object), _, and traverse_subpath.

Now, the bindings still aren't available to DTML methods.  But it
shouldn't be difficult to add.

> ...
> So you could get to any or all of those as you need in your method. Of
> course, new users wouldn't have to worry about this until they needed to
> do something that used it.

Right.  An important feature.

Shane