Alan McKean wrote:
Thanks for taking the time to think this through. Let me make sure I understand. What you are proposing would decouple the runtime from the objects but still make it accessible via the ClassLoader. That seems to be solve a major part of the problem, but doesn't it still leave the metaclass hierarchy coupled to the object? If we persist (or serialize) the object, we would want to replace the metaclass reference with enough information to be able to restore the metaclass reference when the object is paged back in from disk (or deserialized). I was thinking that we had to decouple the runtime so that we wouldn't be persisting things like threads AND decouple the metaclass so that we wouldn't be storing metaclass hierarchy and all of the method dictionaries. Of course, storing the classes and methods would open the door for a shared development environment, so maybe we would want to flush that to the persistent store, too. But it seems like that would not be what we want for serialization.
I'm leaning toward the second example now, where you control the deserialization of the objects and can provide a runtime at that point. In general I'm not sure it's going to be practically possible to decouple the object from runtime completely, because they still need a place to get at runtime-global state, like classes, global variables, and thread contexts. If we forced a JVM-global or classloader-global place to find those things, then we could eliminate the runtime dependency, but we'd also make it far more difficult or even impossible to have multiple separate runtime worldspaces in the same JVM...
- Charlie --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
