From: Mathieu Bouchard <matju@...>
Date: 2001-10-26T15:16:12+09:00
Subject: [ruby-talk:23401] Re: stack_frames patch


On Mon, 22 Oct 2001, Paul Brannan wrote:
> On Mon, 22 Oct 2001, Robert Feldt wrote:
> > Yes, this is a better approach than previous proposals and IMHO the
> > "right" way to do it.
> It certainly looks cleaner, but to get the binding n levels up looks to be
> O(n)?  Generally speaking, I only want the immediate caller's binding
> anyway, so this isn't too big a deal.

Usually,
  1. you want them all (this is O(n))
  2. you want the first one (or to walk them one by one as needed)

Kernel.caller does #1
binding.caller (my proposal) does #2
#1 can be implemented in terms of #2
you can't implement a O(1) immediate-caller lookup using Kernel.caller

> One disadvantage of both proposals is that having access to the caller's
> binding can be VERY dangerous.

Wow. Big deal. It has been said that being able to redefine everything is
dangerous, that being able to override a classes' methods from a mixin is
dangerous, that the mutability of Strings is dangerous, ad nauseam.

There are a million ways to crash in Ruby. They're usually funnier than
the ways of crashing in C.

> But it is already possible to use a hack to get the caller's binding
> (as I show below, and as matju has shown in [ruby-talk:12401],

yup, by violation of causality! =) don't you love unix.

> Perhaps it would be nice if it were possible to get "read-only access" to
> the caller's binding?

read-write is better. Anyway I don't know how you'd effectively get a
read-only access.

> > If its accepted Kernel.caller should probably be deprecated...
> Or perhaps implemented in terms of the proposed methods.

Yes.

________________________________________________________________
Mathieu Bouchard                   http://hostname.2y.net/~matju