Question about the behavior of reopening a module and including another module.

Discussion in 'Ruby' started by Zev Blut, Nov 23, 2004.

  1. Zev Blut

    Zev Blut Guest

    Hello,

    Recently a colleague and I discovered that our understanding of how
    modules work, with regards to reopening a module after being included
    in a class, seems to be at odds with how Ruby actually handles the
    situation.

    I am providing an example of code that highlights the situation.
    What do you think will happen?
    My expectations are given after the code.

    ------------------------------
    module LangDefault
    def foo
    :LangDefault
    end
    end

    module XLang
    include LangDefault
    end

    module JLang
    def foo
    :JLang
    end
    end

    class Talk
    include XLang
    end

    tlk = Talk.new
    puts tlk.foo

    module XLang
    include JLang
    end

    puts tlk.foo
    puts Talk.new.foo

    class Write
    include XLang
    end

    puts Write.new.foo

    puts Talk.included_modules.join(",")
    puts Write.included_modules.join(",")

    class Talk
    include XLang
    end

    puts Talk.new.foo

    ------------------------------


    I assumed that once XLang included JLang, after the first time Talk
    included XLang, that Talk would also recognize this change. Thus, an
    instance of Talk's invocation of foo after XLang included JLang would
    return :JLang instead of :LangDefault. This is what an instance of
    Write's invocation does. Unfortunately, Talk does not do this until I
    include XLang in Talk.


    Is this a design decision or an implementation issue?
    I ask, because I would like to further refine my understanding of
    modules and I am looking for techniques for run time extension of a
    program. Currently, the above works except that I have to make sure
    that a module is extended before it is included in any classes.

    Best,
    Zev Blut
     
    Zev Blut, Nov 23, 2004
    #1
    1. Advertising

  2. Zev Blut

    Pit Capitain Guest

    Re: Question about the behavior of reopening a module and includinganother module.

    Zev Blut schrieb:
    > Recently a colleague and I discovered that our understanding of how
    > modules work, with regards to reopening a module after being included
    > in a class, seems to be at odds with how Ruby actually handles the
    > situation.
    >
    > (example snipped)
    >
    > Is this a design decision or an implementation issue?


    You can find a description here:
    http://www.ruby-doc.org/docs/ProgrammingRuby/html/classes.html#UC (if you have
    the paper version see also figure 19.4 on page 247).

    By including a module, anonymous proxy classes pointing to the module and its
    ancestors are added to the ancestors of the including class. If you alter a
    module's ancestors AFTER including the module in a class, the proxy classes
    don't reflect this change.

    I think it's an implementation issue.

    Regards,
    Pit
     
    Pit Capitain, Nov 23, 2004
    #2
    1. Advertising

  3. Zev Blut

    Zev Blut Guest

    Hello,

    On Wed, 24 Nov 2004 06:31:18 +0900, Pit Capitain <> wrote:

    > You can find a description here:
    > http://www.ruby-doc.org/docs/ProgrammingRuby/html/classes.html#UC (if
    > you have the paper version see also figure 19.4 on page 247).


    Thanks for the link, it certainly helps describe how it is implemented.

    > By including a module, anonymous proxy classes pointing to the module
    > and its ancestors are added to the ancestors of the including class. If
    > you alter a module's ancestors AFTER including the module in a class,
    > the proxy classes don't reflect this change.
    >
    > I think it's an implementation issue.


    Yeah probably so.
    Are there plans to change this in Ruby 2.0?

    Best,
    Zev
     
    Zev Blut, Nov 24, 2004
    #3
  4. On Wednesday 24 November 2004 05:24 am, Zev Blut wrote:
    | Hello,
    |
    | On Wed, 24 Nov 2004 06:31:18 +0900, Pit Capitain <> wrote:
    | > You can find a description here:
    | > http://www.ruby-doc.org/docs/ProgrammingRuby/html/classes.html#UC (if
    | > you have the paper version see also figure 19.4 on page 247).
    |
    | Thanks for the link, it certainly helps describe how it is implemented.
    |
    | > By including a module, anonymous proxy classes pointing to the module
    | > and its ancestors are added to the ancestors of the including class. If
    | > you alter a module's ancestors AFTER including the module in a class,
    | > the proxy classes don't reflect this change.
    | >
    | > I think it's an implementation issue.
    |
    | Yeah probably so.
    | Are there plans to change this in Ruby 2.0?

    It is a rather fundamental problem, so is not likely to get addressed.
    Thankfully, it is extremely rare for it to be a problem.

    There has been some talk of this on suby-ruby, with a possible solution or
    two, but they have performace downsides.

    T.
     
    trans. (T. Onoma), Nov 24, 2004
    #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. Lloyd Sheen

    Reopening project loses <PARAM's

    Lloyd Sheen, Nov 18, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    352
    Lloyd Sheen
    Nov 18, 2003
  2. T Driver

    Re-reading a Stream without reopening

    T Driver, Jun 5, 2007, in forum: ASP .Net
    Replies:
    8
    Views:
    404
    T Driver
    Jun 7, 2007
  3. Logan Capaldo
    Replies:
    0
    Views:
    149
    Logan Capaldo
    Aug 13, 2006
  4. Joseph Ellis
    Replies:
    1
    Views:
    122
    Tassilo v. Parseval
    Jul 25, 2003
  5. Replies:
    2
    Views:
    149
Loading...

Share This Page