I realize this will vary from language to language, but generally we will
need a PMC that encapsulates a method (and responds to the invoke vtable
method like Sub, or maybe the Sub PMC could do?). This python code is
interesting:
class A:
def f (self):
print "A.f()"
def g (self):
print "g()"
a = A()
a.f() # output: A.f()
x = a.f # get the method, a limited form of currying
# since the first arg (a==self) is stored
x() # output: A.f()
setattr(A, "f", g) # replace A's f with g
a.f() # output: g()
x() # output (still): A.f() !!!!!!!
Which shows that the dispatch (i.e. selecting which method to call) can
happen before the invocation.
--
Jonathan Sillito
> -----Original Message-----
> From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
>
> At 8:53 PM -0800 1/14/03, Adriano wrote:
> >On Tue, 14 Jan 2003 17:18:22 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >
> >Dan:
> >>You're off. It'll be something like:
> >>
> >>callmethod Px, "method_name"
> >>
> >>or
> >>
> >>jmpmethod Px, "method_name"
> >
> >Jonathan:
> >>Is there going to be any way to (in PASM) find a method with
> out invoking
> >>it? I am not sure, but it may be useful for currying and some efficiency
> >>stuff (like moving dispatch outside of a loop that repeatedly invokes a
> >>method).
> >
> >Dan:
> >>Yep. There should be a can operator, though I'm not sure how often
> >>one wants to check for the existence of a method in an object
> >>without calling it. But no reason not to. More for rev 2.
> >
> >I think what Jonathan asked for was an operator for returning a
> >method (as an object) which can be invoked later with some arguments
> >(or even applied with a partial list of arguments for currying).
> >This would be a lot more useful than a yes-or-no answer about
> the existence
> >of a method.
>
> I thought about this--it's what the find_method vtable method was for
> in the first place. Unfortunately, as was pointed out to me, there's
> no good way to cache the result, since it could potentially be wrong
> by the time the method is actually called.
>
> We could potentially get around this if we put in place a
> notification framework to invalidate these method handles, but that
> means we have to have a fair amount of infrastructure in place to do
> that. (Though, honestly, I do really like the idea, as it means we
> can be faster by default and just pay the price when things change,
> but there's that pesky code that needs writing and systems that need
> designing to support it...)
> --
> Dan
>
> --------------------------------------"it's like this"-------------------
> Dan Sugalski even samurai
> [EMAIL PROTECTED] have teddy bears and even
> teddy bears get drunk
>
