Forum: Ruby Eval needs explicit self for accessor methods?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
14b490336a66585f67f7fab744128d7d?d=identicon&s=25 tfdj (Guest)
on 2006-04-01 17:10
hi all!

  i encountered a strange problem with eval. please see the following
test case:


require 'test/unit'

class TestContext

  def eval_in_context( ruby_code )
    instance_eval ruby_code
  end

  def toast
    @toast
  end

  def toast=( val )
    @toast = val
  end

end



class TestMetaEval < Test::Unit::TestCase

  def test_toast
    tc = TestContext.new
    tc.toast = 'yes'

    assert_equal 'yes', tc.toast
    assert_equal 'yes', tc.eval_in_context( "toast" )

    # These two lines - using explicit self - work as expected:
    assert_equal 'maybe', tc.eval_in_context( "self.toast = 'maybe'" )
    assert_equal 'maybe', tc.toast

    # What is happening here:
    assert_equal 'no', tc.eval_in_context( "toast = 'no'" )

    # Why does the next test fail?
    # What did the previous line set? A local variable?

    # tc.toast returns 'maybe' here instead of the expected 'no':
    assert_equal 'no', tc.toast
  end

end


  why is the 'toast=(val)' method not visible in eval unless i
explicitly use "self.toast = ..."?

  what is it i don't understand about ruby scoping? :/

any help really appreciated!

cheers,

daniel
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Trans (Guest)
on 2006-04-01 17:29
(Received via mailing list)
It really has nothing to do with eval, your just setting a local
variable.

An unfortuate side effect of the setter notation is that it conflicts
with local var setting. Local var setting wins out, so you have to use
self as the reciever in order to tell ruby you mean the setter method.

T.
14b490336a66585f67f7fab744128d7d?d=identicon&s=25 tfdj (Guest)
on 2006-04-01 17:43
Of course! Thank you! Sorry for the dumb question. Makes perfect sense
now..

dl
06db81f02537377c4bb207cdf8fd18ec?d=identicon&s=25 Mike Austin (Guest)
on 2006-04-01 21:16
(Received via mailing list)
Trans wrote:
> It really has nothing to do with eval, your just setting a local
> variable.
>
> An unfortuate side effect of the setter notation is that it conflicts
> with local var setting. Local var setting wins out, so you have to use
> self as the reciever in order to tell ruby you mean the setter method.
>
> T.

Since you bring this up, there are a few more cases where implicit
locals
declaration causes unexpected behavior (if new to ruby that is):

x = 10
(1..10).each { |i| x = x + i }  # x == 65
x = 10
(1..10).each { |i| x = i }  # x == 10

So if you're assigning x to itself in some way, it recognizes x in the
enclosing scope, else it creates a new local.  That's kind of a
confusing rule.
    Also, what if I wanted the first example to create a local?  How do
I refer
to the toplevel `x` in the second?

I'd really like to see explicit locals declarations in Ruby, and this
would all
be solved by simply introducing `var` or `local`, as in `var x = 10`.
Even if
it was only optional, and invoked with -strict-locals, I think many
people
would be happy.  Maybe I'll download the source and hack away to test it
:)


Mike
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2006-04-01 21:56
(Received via mailing list)
On Apr 1, 2006, at 2:13 PM, Mike Austin wrote:
> So if you're assigning x to itself in some way, it recognizes x in
> the enclosing scope, else it creates a new local.  That's kind of a
> confusing rule.    Also, what if I wanted the first example to
> create a local?  How do I refer to the toplevel `x` in the second?

The 'x' in each of those blocks references the local variable 'x'
defined outside the block.
In neither case is a new local variable 'x' created within the
block.  In both cases a new
local variable 'i' is created within the blocks and is only visible
within the individual block.

Here are the rules I use to understand local variable scope and blocks:

1) Local variables *created* outside a block are visible inside the
block.

2) Local variables *created* inside a block are *not* visible outside
the block.

3) Block arguments behave like *local* variables *not* formal
(method) arguments.


If you combine 1 and 2 you see that block scope is sort of a one-way
barrier. Code inside the block can see variables created outside the
block but not the other way around.

The third rule is the one that throws everyone because most
programmers tend to think of block arguments as formal arguments that
shadow any similarly named variables outside the block but this is
incorrect (in Ruby).  Block arguments behave like *local* variables
so if a block argument has the same name as a variable in the
enclosing scope then a new local variable is *not* created.  On the
other hand if there is no local variable in the enclosing scope with
the same name then a new local variable *is* created and is only
visible within the block (rule 2).

I believe it is rule 3) that Matz is considering changing for Ruby 2.0


Gary Wright
E34b5cae57e0dd170114dba444e37852?d=identicon&s=25 Logan Capaldo (Guest)
on 2006-04-01 22:33
(Received via mailing list)
On Apr 1, 2006, at 2:53 PM, gwtmp01@mac.com wrote:

> (method) arguments.
Good list!
06db81f02537377c4bb207cdf8fd18ec?d=identicon&s=25 Mike Austin (Guest)
on 2006-04-01 23:55
(Received via mailing list)
gwtmp01@mac.com wrote:
>>
> within the individual block.
>
> new local variable is *not* created.  On the other hand if there is no
> local variable in the enclosing scope with the same name then a new
> local variable *is* created and is only visible within the block (rule 2).
>
> I believe it is rule 3) that Matz is considering changing for Ruby 2.0

Changing the hiding characteristics of formal arguments sounds like a
good
idea, but there's still a big problem of not being able to declare
locals.  For
example, given the following:

def test()
   a = 2
   Proc.new { Proc.new { a = 10 }.call() }.call()
   puts a
end

test()  => 10

Lexical closure are a very nice thing, but if I think I'm creating a
local when
in fact I'm modifying some value in the enclosing scope, then that's
bad.  I
think shadowing a parameters is a lot less dangerous, and a warning can
be
printed when that happens.  So the above would look like this:

Proc.new { Proc.new { var a = 10 }.call() }.call()


Mike
93d566cc26b230c553c197c4cd8ac6e4?d=identicon&s=25 Pit Capitain (Guest)
on 2006-04-02 16:51
(Received via mailing list)
Mike Austin schrieb:
> confusing rule.    Also, what if I wanted the first example to create a
> local?  How do I refer to the toplevel `x` in the second?

Mike, you're accessing the toplevel "x" in both cases:

   x = nil
   (1..10).each { |i| x = i }  # x == 10

Regards,
Pit
This topic is locked and can not be replied to.