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

Reply via email to