At 11:44 AM -0600 1/15/03, Garrett Goebel wrote:
Yep. (Horse, meet stick. Stick, meet horse. Prepare to be thumped again)From: attriel [mailto:[EMAIL PROTECTED]]>> > >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. > > Exactly. 'Yes' might be valid one moment, and invalid the > next. Not a very useful operation... Returning a coderef > on the other hand is useful.Er. How could "Is it possible to call this method" become invalid, but the fptr remains valid? I'm not sure that I follow that ...Perhaps I'm misunderstanding Dan's meaning when he talks of invalidating method handles.
I'm not talking about user-level code. I had originally figured that would just walk through the symbol tables and inheritance trees and find the method there and grab it, with no vtable involvement at all--code of the form:
$foo = Bar->can("baz");
doesn't really involve parrot's method code at all. (Or so I thought, though I'm coming to think differently, as even that will need to be delegated to the objects at some point)
I've been concerned with cases like:
foo->bar
foo->bar
foo->bar
where the compiler would be getting foo's bar method once, sticking it into a PMC reg, and invoking it three times. Which would be very wrong, as that handle would be potentially really wrong after the first use. (Heck, finding it could potentially invalidate it, making the first use wrong)
The common case for method handles, if they work, is as a shortcut/optimziation for the compiler, not for user code use, so that's what I'm most concerned with.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
