From: Mark Hubbart <discord@...>
Date: 2004-05-03T04:41:58+09:00
Subject: Re: def [](v) xx; return yy; end # returned value is ignored !?


On May 2, 2004, at 11:54 AM, Kristof Bastiaensen wrote:

>>>>    binding.eval{ self }    #=> main
>>>>
>>>
>>> Also here I would remove the eval.  Maybe binding.get_self or
>>> binding.current_object?
>>
>> I guess there could be methods added for that. But I think the eval
>> thing should be there for more general purpose stuff. It would be
>> easier to remember one eval method than five fetching methods.
>>
>> Also, it would be better to call it something other than 'eval' I
>> suppose. #binding_eval?
>>
>> By allowing a simple way of eval'ing code within a binding like that,
>> you end up with a very flexible way of working with bindings.
>
> Yes, Binding#eval with a block could be very useful.
> (Sorry, I think I didn't look at your code good enough).
> I would prefer Binding#eval with a block over Kernel#eval,
> because it would make the meaning more clear.
> Kernel#eval could be made even an alias for Binding#eval. I can see 
> only
> one problem: compilation of local-variables. Inside the eval block, any
> local variables that you don't assign to will be treated as a 
> method-call,
> and this could be annoying, because they may exist in the binding.

I don't understand why local variables would be treated as a method 
call... They aren't treated that way when you eval a string, correct? 
is there something about the compiler that would treat the locals 
differently in a block?

--Mark