Shane Hathaway wrote:
> >
> >
> > 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.

I thought that's what the following proposal was all about? :S

The idea being to have the form:


where FORMAT is in effect the type...

...or have I got that wrong?

> > 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.

Hurm, have I duplicated that with this?

If so, how do we squish the two together?

> > 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.

How about having a 'Method' base class for _all_ methods, as I suggested
in my proposal, which would provide the calling interface as well as
some standard 'Method' management tabs?

I like the idea of having a bindings tab and an argument tab. Why is
that a bad idea? :-)

> 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'll do that in a sec :-)

> 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.

Hmm, might make more sense when I play with it :-)

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

Cool, is this going toward what I was saying about Zope having a generic
'Method' interface?

> > 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.

Hehe :-)



Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to