On Tuesday 25 November 2003 05:46 am, Dmitry V. Sabanin wrote:
> On Tuesday 25 November 2003 02:02, T. Onoma wrote:
> > No. Eval is for constructing code piecemeal with various variables, not
> > just to do what can already be done without it. But as it stands, one
> > must build literals within strings to accomplish such things. That's a
> > lot of extra work and makes for choppy ugly code.
>
> I think that eval just gives access to ruby interpreter itself in run-time.
> How could it behave differently from ruby then, if it _is_ ruby? That's
> just a needless ambiguity.
>
> > Of course, the above example dosen't really do what I want it to. For
> > that, I have to get fancy:
> >
> >   p "#{a.join(',')}"
>
> You can just do p "#{a.inspect}", as it works great with strings, arrays
> and hashish..oops..hashes :). Or you always can define a method, i.e.
> to_evil in String, Array, Hash, or in any other class you use in eval, and
> use it like #{a.to_evil}.
> As I see it, it's just ten lines or so.

Hey! That's a workable solution. Not quite as clean, but it works for me. 
Hmm...think i'll alias #i, or something small, for inspect. Nice.

> You can't change ruby behavior for things just to make it more comfortable
> for you, sometimes you have to change the way _you_ do it.

I wouldn't hold on to that argument too tightly, otherwise you might find 
yourself programming in Assemby ;)

But if you mean JUST ME, then I wouldn't. I suggested it b/c I thought it 
would be useful in general, and others might like to have it to. But your 
solution in concise enough. So it's all good.

BTW: This idea first came out of my considering, "what-if" all blocks were 
locally scoped-off, how would you get to variables outside? I thought of 
"holes". With a notation like:

  a = "hole"
  { "This is a block with a" + |a| + " in it." }

So when I was working with complex evals I kept thinking, "Ugh, I wish I had 
that."

Thanks!
-t0