[ANN] parseargs-0.0.0

[Pit Capitain]

hmm. i guess here

def a; 'forty-two'; end

set_var 'a', 42
p a

we get the method. and here

def a; 'forty-two'; end

a = 42
p a

we get the local_variable. so in either case you get a name clash -
but the sense of it is reversed with set_var.

Yes, this is what I wanted to show. "Name clash" was the wrong term.

i wonder if this is un-intuitive enough to render it useless?

Oh no, this isn't useless at all! Don't get me wrong. I only wanted to
show the difference to "normal" local variables.

Regards,
Pit

 

[Ara.T.Howard]

Yes, this is what I wanted to show. "Name clash" was the wrong term.


Oh no, this isn't useless at all! Don't get me wrong. I only wanted to show
the difference to "normal" local variables.

check.

any idea just how stable binding_of_caller is? the code looks fine - i just
wonder if it'll blow up on the next release or not... seems like such a
fantastic candidate for an RCR it's not even funny.

cheers.

-a
--
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| My religion is very simple. My religion is kindness.
| --Tenzin Gyatso
===============================================================================

 

[Zev Blut]

Hello,

Sorry for the late reply.

It is a curious side effect of the way Ruby is interpreted. Perhaps it
is a performance optimization? It doesn't really have to be this way,
but it won't affect you (much) in practical terms.

Variables that are "visible" when a method is compiled are added to a
table somewhere in the AST, and only those variables can be accessed
directly in that method. Clearly, this table is not the same one that
"eval" consults so we have, to put it diplomatically, a little
disconnect. Eval can find the variable when asked, but the interpreter
simply refuses to go looking for it in the first place.

Thanks a lot for the explanation! It certainly makes sense now.

Cheers,
Zev