remove_const, Kernel.load, and already instantiated objects

Discussion in 'Ruby' started by Brent Dillingham, Aug 23, 2008.

  1. Context: I'm programming a MUD in Ruby for fun and profit--if one
    considers that an increase in knowledge == profit. :)

    Up to this point, I've only ever done web work with Ruby using Rails,
    Merb, etc., so I wanted to embark on a from-scratch project, and MUDs
    happen to be a favorite old pastime of mine ;)

    One of the things I'm trying to do is implement a development server
    that "reloads" my source files automatically when they're updated,
    just like Rails or Merb does. Meaning that I can connect to the MUD
    server and explore with my test character, while updating my source
    files to change behavior around on the fly.

    So, reading through Merb's way of doing it, I've gathered that in
    order to properly "reload a class", one must use remove_const to
    "undefine" the Class constant, and then use Kernel.load to reload the
    Class' source file. Simple stuff, and with a separate thread that
    continuously monitors my source files for changes in their
    modification time, we're golden. It works great.... with one exception.

    What about objects of a Class that were already instantiated -- before
    the Class is reloaded with its changes? Those objects are essentially
    still bound to the "old" Class, I've found, and do not reflect the
    reloaded Class's changes. This doesn't really affect Rails or Merb,
    since Controller and Model instances do not persist between HTTP
    requests, but it certainly affects a MUD, where my test character (and
    basically everything else) is always in the object space.

    The following IRB session demonstrates: (also on pastie: http://pastie.org/258400)

    >> puts File.read('foo.rb')

    class Foo
    def hello
    "Hello, world!"
    end
    end
    => nil
    >> require 'foo'

    => true
    >> f = Foo.new

    => #<Foo:0x117fbb4>
    >> f.hello

    => "Hello, world!"

    # Now I update foo.rb...

    >> puts File.read('foo.rb')

    class Foo
    def hello
    "BRAND NEW Hello World!"
    end
    end
    => nil

    # Reload the file using remove_const and Kernel.load

    >> Object.send:)remove_const, :Foo)

    => Foo
    >> Kernel.load('foo.rb')

    => true

    # Existing instance of Foo DOES NOT use the updated method.

    >> f.hello

    => "Hello, world!"

    # New object DOES use the updated method.

    >> f2 = Foo.new

    => #<Foo:0x112c6f8>
    >> f2.hello

    => "BRAND NEW Hello World!"


    So here's the question -- is there some way to get an object to...
    erm, "reset" its Class? Sounds like evil voodoo that could potentially
    make things explode, but I'd truly like to see this thing work :) If
    it's just not possible though, I can live with that.

    BTW -- By not doing the remove_const on the Class, I can sort of get
    this to work, because reloading the file with Kernel.load will
    effectively just reopen the class definition, adding the new changes,
    but also not removing methods I've deleted. And this *does* make
    things explode, like DataMapper for one, and I get all kinds of
    "already initialized constant" warnings.

    The only thing I can think of is to try to finagle a way to copy
    existing objects into the newly defined Class, using serialization or
    something crazy, but that sounds really messy and probably not worth it.

    Any comments? -- ideas / thoughts / similar-experience / you're-an-
    idiot-for-even-trying-this? Thanks! :)

    Brent
     
    Brent Dillingham, Aug 23, 2008
    #1
    1. Advertising

  2. On Fri, Aug 22, 2008 at 6:47 PM, Brent Dillingham
    <> wrote:
    >
    > The only thing I can think of is to try to finagle a way to copy existing
    > objects into the newly defined Class, using serialization or something
    > crazy, but that sounds really messy and probably not worth it.


    Not *that* messy - you basically walk the object space, marshal
    everything, reload the class and unmarshal it. Works fine as long as
    you don't want to restore closures.

    martin
     
    Martin DeMello, Aug 23, 2008
    #2
    1. Advertising

  3. Brent Dillingham

    Peña, Botp Guest

    From: Brent Dillingham [mailto:]=20
    # ...
    # >> puts File.read('foo.rb')
    # class Foo
    # def hello
    # "Hello, world!"
    # end
    # end
    # =3D> nil
    # >> require 'foo'
    # =3D> true

    ok. you used require

    # # Reload the file using remove_const and Kernel.load
    # >> Object.send:)remove_const, :Foo)
    # =3D> Foo
    # >> Kernel.load('foo.rb')
    # =3D> true

    now you use load.

    let us stick to require... ;)

    irb(main):001:0> require 'foo.rb'
    =3D> true
    irb(main):002:0> f=3DFoo.new
    =3D> #<Foo:0x2900af4>
    irb(main):003:0> f.hello
    =3D> "hello"

    ok

    irb(main):004:0> require 'foo.rb'
    =3D> false
    irb(main):005:0> f.hello
    =3D> "hello"

    as expected, no change.
    let's see if we can cheat ;)

    irb(main):006:0> $LOADED_FEATURES
    =3D> ["e2mmap.rb", "irb/init.rb", "irb/workspace.rb", "irb/context.rb", =
    "irb/extend-command.rb", "irb/output-method.rb", "irb/notifier.rb", =
    "irb/slex.rb", "irb/ruby-token.rb", "irb/ruby-lex.rb", "readline.so", =
    "irb/input-method.rb", "irb/locale.rb", "irb.rb", "irb/ext/history.rb", =
    "irb/ext/save-history.rb", "foo.rb"]

    ah

    irb(main):007:0> $LOADED_FEATURES.delete "foo.rb"
    =3D> "foo.rb"

    irb(main):008:0> require 'foo.rb'
    =3D> true
    irb(main):009:0> f.hello
    =3D> "new hello"

    is that ok?
    ... caveat, i'm not sure if that is documented/supported. maybe, verify =
    fr matz or nobu..

    kind regards -botp
     
    Peña, Botp, Aug 23, 2008
    #3
  4. Thanks for the replies!

    Botp, your "cheat" does indeed allow you to use require again to load =20=

    the source file, but this is actually doing the same thing as using =20
    Kernel.load. It's just interpreting the contents of foo.rb again, =20
    effectively reopening class Foo. Kernel.load is just like require, =20
    only require checks $LOADED_FEATURES I guess before it blindly =20
    interprets the content of your file again. Kernel.load doesn't do any =20=

    such check; it interprets the file you point it to no matter what.

    I did try it, but unfortunately DataMapper still complains about =20
    missing properties and such on existing objects after the reload. And =20=

    the problem still remains that we are not truly "reloading" the =20
    class ... we're just reopening it, adding or overwriting methods, just =20=

    like we might in an IRB session.

    I did try to go the Marshal route, but Marshal.dump chokes when trying =20=

    to dump most of my objects with "TypeError: can't dump hash with =20
    default proc". I don't know exactly what that's referring to (the =20
    stack trace is useless), but it probably has something to do with a =20
    DataMapper feature. Marshal seems to be pretty unreliable for any kind =20=

    of non-trivial object, and I think doing any kind of "deep copy" on my =20=

    objects will lead to weird duplication issues with their associations =20=

    anyway. e.g. two Player objects in the same Room need to refer to the =20=

    same object_id for player.room (at least, that's the assumption I'm =20
    designing under right now to prevent hitting the DB constantly). If I =20=

    do a deep copy as Marshal.dump(player) would do, I'll end up with the =20=

    players referring to two brand new, different copies of Room objects. =20=

    Which is bad, I think.

    Though it's possible that I'm making a mistake by relying on the Room =20=

    objects staying in-memory. I need to read up on how garbage collection =20=

    works.

    At any rate, I'm about to give up on this idea unless anyone has any =20
    other suggestions. Thanks!

    Brent


    On Aug 23, 2008, at 12:05 AM, Pe=F1a, Botp wrote:

    > From: Brent Dillingham [mailto:]
    > # ...
    > # >> puts File.read('foo.rb')
    > # class Foo
    > # def hello
    > # "Hello, world!"
    > # end
    > # end
    > # =3D> nil
    > # >> require 'foo'
    > # =3D> true
    >
    > ok. you used require
    >
    > # # Reload the file using remove_const and Kernel.load
    > # >> Object.send:)remove_const, :Foo)
    > # =3D> Foo
    > # >> Kernel.load('foo.rb')
    > # =3D> true
    >
    > now you use load.
    >
    > let us stick to require... ;)
    >
    > irb(main):001:0> require 'foo.rb'
    > =3D> true89
    > irb(main):002:0> f=3DFoo.new
    > =3D> #<Foo:0x2900af4>
    > irb(main):003:0> f.hello
    > =3D> "hello"
    >
    > ok
    >
    > irb(main):004:0> require 'foo.rb'
    > =3D> false
    > irb(main):005:0> f.hello
    > =3D> "hello"
    >
    > as expected, no change.
    > let's see if we can cheat ;)
    >
    > irb(main):006:0> $LOADED_FEATURES
    > =3D> ["e2mmap.rb", "irb/init.rb", "irb/workspace.rb", "irb/=20
    > context.rb", "irb/extend-command.rb", "irb/output-method.rb", "irb/=20
    > notifier.rb", "irb/slex.rb", "irb/ruby-token.rb", "irb/ruby-lex.rb", =20=


    > "readline.so", "irb/input-method.rb", "irb/locale.rb", "irb.rb", =20
    > "irb/ext/history.rb", "irb/ext/save-history.rb", "foo.rb"]
    >
    > ah
    >
    > irb(main):007:0> $LOADED_FEATURES.delete "foo.rb"
    > =3D> "foo.rb"
    >
    > irb(main):008:0> require 'foo.rb'
    > =3D> true
    > irb(main):009:0> f.hello
    > =3D> "new hello"
    >
    > is that ok?
    > ... caveat, i'm not sure if that is documented/supported. maybe, =20
    > verify fr matz or nobu..
    >
    > kind regards -botp
    >
    >
     
    Brent Dillingham, Aug 23, 2008
    #4
  5. On Sat, Aug 23, 2008 at 9:05 AM, Brent Dillingham
    <> wrote:
    >
    > I did try to go the Marshal route, but Marshal.dump chokes when trying to
    > dump most of my objects with "TypeError: can't dump hash with default proc".
    > I don't know exactly what that's referring to (the stack trace is useless),
    > but it probably has something to do with a DataMapper feature. Marshal seems
    > to be pretty unreliable for any kind of non-trivial object, and I think
    > doing any kind of "deep copy" on my objects will lead to weird duplication


    Hm - if you're persisting to a database, what I'd recommend is
    implementing a load and save feature, then doing a save/reload
    class/load cycle when code changes. It will require a bit of up front
    work to distinguish between game state and incidental state, but that
    should improve your design too, and simplify the rest of your code
    moving forward.

    martin
     
    Martin DeMello, Aug 23, 2008
    #5
  6. Yeah, I guess that's the only remaining solution.

    Essentially what I'd be doing I guess is a "live reboot", where every
    single game object gets recreated. And you're right that dealing with
    incidental state vs. the state in the DB will be a bit hairy. But hey,
    I like a good challenge :) And you're right, it would probably force
    me to think a lot harder about the state of my game objects and what I
    choose persist to the DB.

    A bit saddening is that through some Googling I found that this kind
    of thing seems to be a bit more feasible in Python. In python you can
    actually take an existing object and do object.__class__ =3D MyClass
    after the class is reloaded! This doesn't appear to be possible in
    Ruby, but I think it's the sort of thing I was looking for initially.
    It still sounds like voodoo to me, actually. I lack the low-level
    knowledge to understand how that would even be implemented!

    Brent



    On Aug 23, 4:33=A0pm, "Martin DeMello" <> wrote:
    > On Sat, Aug 23, 2008 at 9:05 AM, Brent Dillingham
    >
    > <> wrote:
    >
    > > I did try to go the Marshal route, but Marshal.dump chokes when trying =

    to
    > > dump most of my objects with "TypeError: can't dump hash with default p=

    roc".
    > > I don't know exactly what that's referring to (the stack trace is usele=

    ss),
    > > but it probably has something to do with a DataMapper feature. Marshal =

    seems
    > > to be pretty unreliable for any kind of non-trivial object, and I think
    > > doing any kind of "deep copy" on my objects will lead to weird duplicat=

    ion
    >
    > Hm - if you're persisting to a database, what I'd recommend is
    > implementing a load and save feature, then doing a save/reload
    > class/load cycle when code changes. It will require a bit of up front
    > work to distinguish between game state and incidental state, but that
    > should improve your design too, and simplify the rest of your code
    > moving forward.
    >
    > martin
     
    Brent Dillingham, Aug 24, 2008
    #6
  7. Brent Dillingham wrote:
    > Yeah, I guess that's the only remaining solution.
    >
    > Essentially what I'd be doing I guess is a "live reboot", where every
    > single game object gets recreated. And you're right that dealing with
    > incidental state vs. the state in the DB will be a bit hairy. But hey,
    > I like a good challenge :) And you're right, it would probably force
    > me to think a lot harder about the state of my game objects and what I
    > choose persist to the DB.


    Since it seems like you're trying to specialize the garbage collector,
    perhaps the easiest way is to implement your own higher-level garbage
    collector:

    class MyObjects is a singleton which holds a persistent, mutable array
    of objects with these kinds of methods:

    def add(obj)
    @arr.push(obj)
    end

    def clear
    @arr.collect { |x| x.expired = true }
    @arr.replace([])
    end

    Then in your "I want these to disappear when I say so" classes:

    attr_writer :expired

    def initialize
    @expired = false
    MyObjects.add(self)
    end

    def some_call
    raise StandardError if @expired # some form of AOP is desirable here
    end

    And in your "reload" code:

    def reload_class
    MyObjects.clear
    load 'foo.rb'
    end

    It's ugly but it's precise, and will make the old objects complain
    loudly until ruby's ready to garbage collect them, making things easier
    for you to debug and manage. This will be most evident if you do any
    kind of anonymous routine management and closures get involved heavily.

    That said, I've never been fond of schemes that treat namespaces as
    fully mutable at any time; it reeks of poor design and you end up with
    schemes like this if you want to get it right.

    -Erik
    --
    Posted via http://www.ruby-forum.com/.
     
    Erik Hollensbe, Aug 24, 2008
    #7
  8. Erik Hollensbe wrote:
    > It's ugly but it's precise, and will make the old objects complain
    > loudly until ruby's ready to garbage collect them, making things easier
    > for you to debug and manage. This will be most evident if you do any
    > kind of anonymous routine management and closures get involved heavily.


    I should probably note that code in it's current state would keep
    objects around that weren't intended to stay around otherwise (that is,
    they would be GC'd by ruby before you did any reloading), so you'd have
    to implement some form of hackneyed destructor as well.

    -Erik
    --
    Posted via http://www.ruby-forum.com/.
     
    Erik Hollensbe, Aug 24, 2008
    #8
    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. J
    Replies:
    1
    Views:
    290
  2. yogesh
    Replies:
    3
    Views:
    595
    Kenny McCormack
    Feb 12, 2006
  3. Replies:
    3
    Views:
    179
  4. jko170
    Replies:
    1
    Views:
    137
    Rick DeNatale
    Sep 22, 2009
  5. Lars Gierth
    Replies:
    6
    Views:
    233
    David Masover
    Mar 20, 2010
Loading...

Share This Page