On Sun, 11 Jan 2009 22:27:29 -0500, Charles Oliver Nutter wrote:

> Ken Bloom wrote:
>> Second, the trace function is only being used for a couple of calls
>> before the continuation is called, and execution jumps back into
>> Binding.of_caller at which point the trace function is removed. It
>> wouldn't appear to me like it would hurt things too much. (Maybe it
>> requires turning on an otherwise disabled feature in JRuby?)
> 
> Tracing works, but JRuby and IronRuby do not support continuations, and
> I think they work differently in 1.9. It's a hack that's unlikely to
> work reliably, even across minor versions of a given implementation.
> 
> In general I think Binding.of_caller is a really, really bad idea
> because it exposes internal details every method call in *your* code to
> the whims of *someone else's* code. Basically, it breaks the most sacred
> encapsulation possible, a method call's local variables.
> 
> Imagine a case like this:
> 
> def secure_action(encrypted_password)
>    decrypted_password = decrypt(encrypted_password)
>    authorize(decrypted_password)
>    do_secure_task
> end
> 
> If it were possible to modify do_secure task, or if you were simply
> calling a third-party library, it could access the runtime variables of
> the caller:
> 
> def do_secure_task
>    binding = Binding.of_caller
>    vars = eval 'local_variables', binding vars.each do |name|
>      if name =~ /password/
>        use_for_evil(eval name, binding)
>      end
>    end
> end
> 
> I even implemented Binding.of_caller for fun once in JRuby, and removed
> it when I realized how invasive and dangerous it was.
> 
> Just like retry was limited in 1.9 to restarting a rescued block of code
> (rather than being able to reevaluate the original arguments and
> receiver), Binding.of_caller should remain unsupported.
> 
> - Charlie

It turns out that Binding.of_caller isn't a hack I need. It's a hack I 
though I needed when I thought I'd have to use Ripper to fix s-expression 
generation in the SqlStatement for Ruby 1.9. Then I discovered that all 
the operators I needed were now overloadable, so I went with that instead.

Which reminds me of another question I had. You were discussing somewhere 
else how Thread.critical works in JRuby. Does Thread.critical / 
Thread.exclusive in JRuby protect other threads against changes to the 
core class methods? Can I run Thread.critical=true , dramatically 
redefine operators on the core classes, redefine the operators back  
their original implementations, run Thread.critical=false, and expect 
that no other JRuby thread can get in and be broken becuase I've 
dramatically gutted the core classes?

-- 
Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/