ruby eval magic

Discussion in 'Ruby' started by DMG, Dec 14, 2009.

  1. DMG

    DMG Guest

    Can anybody explain me, why this is true:
    self.class.class_eval{self} == self.class.instance_eval{self}

    Thanks,
    Dawid
    DMG, Dec 14, 2009
    #1
    1. Advertising

  2. DMG

    Guest

    On Dec 14, 10:33 am, DMG <> wrote:
    > Can anybody explain me, why this is true:
    > self.class.class_eval{self} == self.class.instance_eval{self}
    >
    > Thanks,
    > Dawid


    It seems that we don't need class_eval method. Because if we use a
    Module or Class directly, we can use:
    SomeClass.instance_eval { ... }

    and if we have an object and we need to work on its class, we can use:
    some_object.class.instance_eval { ... }

    So, do we need class_eval/module_eval?

    Thanks,
    Dawid
    , Dec 14, 2009
    #2
    1. Advertising

  3. unknown wrote:
    > It seems that we don't need class_eval method. Because if we use a
    > Module or Class directly, we can use:
    > SomeClass.instance_eval { ... }
    >
    > and if we have an object and we need to work on its class, we can use:
    > some_object.class.instance_eval { ... }
    >
    > So, do we need class_eval/module_eval?


    Yes, we do. But it took me a while until I found out why.

    When Ruby code is executing, there are two bits of state which are
    maintained:
    - the current object, which is exposed as 'self'
    - the current class, where instance methods are defined. This is pretty
    well hidden, but sometimes it matters.

    Try the following code:

    class Foo; end

    Foo.class_eval "def bar; puts 'Hello!'; end"

    Foo.new.bar

    If you change class_eval to instance_eval, it won't work as shown. In
    fact you'll make a class method on Foo (Foo.bar)

    AFAIK, class_eval and module_eval are the same thing though.
    --
    Posted via http://www.ruby-forum.com/.
    Brian Candler, Dec 14, 2009
    #3
  4. DMG

    Guest

    On Dec 14, 11:51 am, Brian Candler <> wrote:
    > When Ruby code is executing, there are two bits of state which are
    > maintained:
    > - the current object, which is exposed as 'self'
    > - the current class, where instance methods are defined. This is pretty
    > well hidden, but sometimes it matters.
    >
    > Try the following code:
    >
    >     class Foo; end
    >
    >     Foo.class_eval "def bar; puts 'Hello!'; end"
    >
    >     Foo.new.bar
    >
    > If you change class_eval to instance_eval, it won't work as shown. In
    > fact you'll make a class method on Foo (Foo.bar)


    Oh, I see. Yes, the context matter when defining methods.
    Thank you very much!
    , Dec 14, 2009
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Eric Newton
    Replies:
    3
    Views:
    9,347
    Brock Allen
    Apr 4, 2005
  2. DataBinder.Eval and Eval.

    , Jun 16, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    519
    Karl Seguin [MVP]
    Jun 16, 2006
  3. Alex van der Spek

    eval('07') works, eval('08') fails, why?

    Alex van der Spek, Jan 8, 2009, in forum: Python
    Replies:
    6
    Views:
    1,401
    Bruno Desthuilliers
    Jan 8, 2009
  4. Sunny Hirai
    Replies:
    1
    Views:
    122
    Alex Young
    Jun 6, 2007
  5. Giles Bowkett
    Replies:
    9
    Views:
    394
    Giles Bowkett
    Dec 17, 2007
Loading...

Share This Page