Re: Objects, finally (try 1)

[Dan Sugalski]

At 8:54 PM +0000 1/15/03, Nicholas Clark wrote:

On Wed, Jan 15, 2003 at 01:00:59AM -0500, Dan Sugalski wrote:

 At 8:53 PM -0800 1/14/03, Adriano wrote:

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

How much infrastructure do you need? I thought perl5 cached method lookup,
but had a global (per interpreter) generation count, which went up by one
every time you (re)defined a method. So for parrot you return a "thingy"
that is initially implemented as the direct pointer, a generation count,
plus enough other stuff to redo the search. If at the time of calling the
generation count is the same, wehay, go for it. Otherwise redo the search
there and then, and update.

What I don't want is to check every time. I want method invalidation to be done only on demand, so the common case (multiple use without intervening redefinition) is as fast as possible. If we do implicit handles we'll need a good infrastructure with defined semantics to make sure those handles get either invalidated or rejigged when changes are made, plus we need them to support the cases where there is no real method and we're faking it all.

I think I know what needs to be designed, and what semantics we need, and I'm pretty sure I know how to fake it until the structure's done, too, so after I dig through the rest of the aftermath here it'll be time to start writing. :)
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk