From: Erik Hollensbe <erik@...>
Date: 2008-08-25T04:59:47+09:00
Subject: Re: remove_const, Kernel.load, and already instantiated objects

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/.