From: michele <michelemendel@...>
Date: 2006-10-27T04:05:17+09:00
Subject: Re: What's the difference between send and instance_eval?


I may not understand it well, but I don't like it. The two methods are
so similar that the only way to figure out the difference is to find
cases that will make it hard or impossible to use one of them. It
should be easy to choose which method to use, not hard to figure out
which one not to use. They are also conceptually different. An object
can either call a method (most common lingo among Java, C, etc) or you
can send it a message (Smalltalk), but what does "eval" mean? Ruby uses
all three (call, send and eval) which may be good (I don't know why,
but maybe if you like to study computer languages), but if I don't use
these methods every day, I will have to think hard every time I need
one of them.


On Oct 26, 7:47 pm, Joel VanderWerf <v...@path.berkeley.edu> wrote:
> Rick DeNatale wrote:
> > On 10/26/06, Joel VanderWerf <v...@path.berkeley.edu> wrote:
>
> >> That's true, but only because I chose a bad example. Here's a better one:
>
> >> h = {1=>2}
> >> msg = [:concat, [4, 5, 6, IO, String, Kernel, h]]
> >> a = [1,2,3]
> >> p a.send(*msg)   # ==> [1, 2, 3, 4, 5, 6, IO, String, Kernel, {1=>2}]
> >> p a.instance_eval(msg.to_s) # ==> NameError
>
> >> To make the instance_eval work here, you would have to find a way to
> >> turn the argument array into a string that, when eval-ed, is that same
> >> array. (It's possible, but painful, and you lose the identity of the
> >> hash h.)
>
> > except that instance_eval can take a block in lieu of a string:
>
> > a.instance_eval {concat [1,2,3,4,5,6,IO,String,Kernel, h]}
> > => [1, 2, 3, 1, 2, 3, 4, 5, 6, IO, String, Kernel, {1=>2}]
>
> > Not that I think that send should be eliminated, both methods are
> > useful. Horses for courses.And I'm starting to beat a dead horse here, but using a block leads you
> to scoping issues. (What if the hash were @h or a method call instead of
> h? You can always use an temporary local var to avoid the issue.)
>
> You're quite right: each method has its place.
>
> --
>        vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407