On Thursday 27 November 2003 12:34 am, Chad Fowler wrote:

> # In this case, it's almost the same situation, but about embedding Ruby
> # code into Ruby code.
> #
>
> There's a big conceptual difference between what is happening with SQL and
> what is happening when you eval something.  I view the SQL scenario as
> being not much different than any other interpreter.Part of the difference
> is host/eval language differences (do you ever eval SQL inside an engine
> which is written in SQL?) but more importantly, eval'ing is generally
> (including the case of Ruby, something that is delegated from one piece of
> code back up to the engine which parsed itself.  I don't see this as being
> related, but it's possible that I'm missing something.

You're just talking a different language, but you're still evaluating. In 
other words you're taking infomation form one context and having it 
proccessed in another. This is the same for eval in ruby. That's why you can 
specify a different binding, for example.

And that's the the thing really. Eval will more often be used with a string 
instead of blocks because strings give you a larger context (scope) to pull 
from.

   a = "hello"
   class_eval "def pa; puts #{a}; end"

   a = "hello"
   class_eval { def pa; puts a; end }

The botttom one won't work.

The way I see it, eval's not just about running code in different bindings and 
class/instance modes, but also pulling information to do it with from 
surrounding scope. That's why I suggested the concept of scope "holes", which 
forgoes the need to turn an object into a string literial in order to be 
eval'd, which can be very burdensome if you have a complex object.

-t0