From: Brian Mitchell <binary42@...>
Date: 2005-10-10T08:45:48+09:00
Subject: Re: using lambda/Proc can prevent a lot of garbage collection

On 10/9/05, Logan Capaldo <logancapaldo@gmail.com> wrote:
>
> On Oct 9, 2005, at 5:31 PM, Joel VanderWerf wrote:
>
> > Eric Hodel wrote:
> >
> >
> >> A closure should only enclose the variables needed for its execution.
> >> This is actually not very difficult but unfortunately eval('a')
> >> prevents
> >> Ruby from excluding unbound variables in closures.
> >>
> >> This is a (unfortunate IMO) feature of Ruby.
> >>
> >>
> >
> > Aren't there some useful hacks that depend on being able to get at
> > vars
> > in the caller's scope (which need not be referenced in the block),
> > using
> >  the
> >
> >   eval str, some_proc
> >
> > construct?
> >
> > I use it in my observable lib to get the self of the block's context,
> > using something like this:
> >
> >       def when_#{var} pattern=Object, &block
> >         observer_map = @#{var}__observer_map ||= ObserverMap.new
> >         if block
> >           observer = eval "self", block
> >
> > to find out what object is observing a variable. But that's not as
> > objectionable as getting access to arbitrary local vars in that
> > context.
> >
> > Does anyone remember--is there is anything that uses the latter
> > kind of
> > access (arb. local vars) that is more than just a cute hack? Is there
> > anything really useful we would lose without that behavior?
> >
> > --
> >       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
> >
> >
>
> Speaking of eval, I've always wondered why ruby of all languages
> needed a string based eval. What can you do with a string eval that
> you can't do with something like:
>
> eval(some_binding) { code }
>
> some_binding of course would be optional just like currently.
>
> with instance_variable_get() and instance_variable_get you
> dynamically get at ivars. with send and/or instance eval you can
> dynamically send messages. define_method blah blah... works just as
> well as eval "def blah blah".  This is something thats always kind of
> irked me. And in my brave new world of evalless ruby, worse case
> scenario you write a string to a temporary file and load it. But I
> really don't believe thats necessary. Can anyone come up with a use
> for an eval taking a string that CAN'T be acheieved by an eval that
> takes a block? (well, irb I suppose). If nothing else I would
> appreciate it greatly if eval could take a block in addition to a
> string. I think this may have come off kind of like, so if I did I
> apologize in advance ;-)

Unfortunately, eval can do things that non-eval-code can't. Little
things like methods that take blocks, easier class definitions, quick
and dirty singleton definitions, etc... These _can_ be solved w/o eval
(well most of them) but it requires more code, more trickery, and/or
more discipline.

With that said, I am all for a Ruby w/o a direct need for eval besides
a REPL. Even a keyword-less way to do everything in Ruby would be nice
(singletons, I'm looking at you).

Brian.