Sandbox.set

Okay, well, a year later… David Stevenson offered a patch on the mailing list for freakyfreaky which adds a method for setting variables inside the Sandbox. This got expanded a bit and has become Sandbox.set!

>> box = Sandbox.safe
>> box.set "radish", "`,"
>> box.eval "radish"
=> "`,"

And the object_ids for the two strings are different. Meaning: it got marshalled in.

However, it’s also smart about passing references in and out.

>> class Katsuhito; end
>> box.ref Katsuhito
>> k = Katsuhito.new
=> (Katsuhito:0xb7d1dce4)
>> box.set "k", k
>> k.class.ancestors
=> [Katsuhito, Object, Kernel]
>> box.eval "k.inspect"
=> "(Katsuhito:0xb7d1dc6c)"
>> box.eval("k.class.ancestors.inspect")
=> "[Katsuhito, BoxedClass, Object, Kernel]"
>> box.eval "k"
=> (Katsuhito:0xb7d1dce4)

This is a bit twisted to look through, but anyway. We’re dealing with two variables here named k. The original k is outside the sandbox. And the second is set inside.

The original k is the real thing. You can see its ancestry is intact. But the k inside the sandbox is descended from BoxedClass. Meaning its just an empty proxy class. More on this at RedHanded.

Oh, and the last line. When k is passed back to the main environment, we get back the original k object!