On Tue, Nov 15, 2005 at 10:17:30AM +0100, Leopold Toetsch wrote:
> Autrijus mentioned on #parrot that we'd need weak pointers at some
> time. Then we can reconsider callframe PMCs.
Ah, weak pointers. I remember a time without weak pointers. It was a
happy time. Birds chirped in the trees....
> >How about if we implement get_caller() on Interpreter and Continuation,
> >rather than Interpreter and Sub?
>
> ... Interpreter and Sub and Continuation ;-) Dropping the interface
> from Sub would again need to expose the RetContinuation [...]
I certainly agree that exposing the RetContinuation, which
automatically promotes it and its whole call chain to a full
Continuation, is not something to do routinely.
However, it's a Bad Thing to put get_caller() or any other such call
frame introspection query into the Sub interface. You might as well
put a filename() query on a Unix inode.[*] That's gotta go, and it's
gotta not come back.
If caller introspection is common enough that invoking a method on
Interpreter is too slow or inconvenient -- and since we can't use
Continuations as the primary interface for caller queries -- I guess
the next step of optimization would be specialized opcodes for call
frame introspection. I hope we don't have to go there, and we can
stick with the Interpreter interface for common usage.
> > Alternatively, I guess we could make
> >get_caller() take two parameters: a Continuation as a starting point
> >(Null would mean "me"), and a number of levels up.
>
> Hmm. That are 3 params in the method: object, start, level. I guess
> this needs first some thoughts, how we handle class methods, when
> invoked by an instance of the class.
What's bad about how it works now? <- not a rhetorical question
[*] an inode may have as few as zero or as many as USHORT_MAX[**] names,
and finding them all requires scanning a disks's entire directory tree
[**] your mileage may vary
--
Chip Salzenberg <[EMAIL PROTECTED]>
