From: Kristof Bastiaensen <kristof@...>
Date: 2004-05-03T03:54:15+09:00
Subject: Re: def [](v) xx; return yy; end # returned value is ignored !?

Hi,

On Sun, 02 May 2004 20:56:47 +0900, Mark Hubbart wrote:
> I see. I momentarily forgot that while you can use methods as lvalues, 
> you have to choose between lvalue and method call; you can't assign to 
> it if you use the parens. I'm scrambling now for a replacement that I 
> like...
> 
> Perhaps:
> 
> binding[:a] = 23
> binding[:a] += 19

Yes, that looks better than my version with value.

>>> also:
>>>
>>>    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.


Kristof