From: Brent Dillingham Date: 2008-08-25T02:28:50+09:00 Subject: Re: remove_const, Kernel.load, and already instantiated objects 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__ = 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 pm, "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 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