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 >