Code-reloading issues

[Brian T. Rice]

Hi,

I thought I'd address quickly why reloading Slate source files is problematic 
currently.

What's at issue is that addPrototype: messages do /not/ modify the existing 
prototype or its traits object in place; not yet, anyway. They still are 
restricted to the Lisp-based implementation limit that objects cannot be re-
defined in place without jumping through hoops, so I left it out.

This means that existing objects will refer to old traits, and that there 
will then be two versions of the behavior in the image, and the old clones 
will not be updated to the new behavior automatically.

With that said, even using the primitive forwardTo: method (in combination 
with a primitive that hasn't been added but is trivial to iterate through all 
users of a given traits object) to replace objects is still not a perfectly-
consistent thing to do. What I'm considering is to adjust the idioms we use 
into something like:

define: Prototype named: #SomeName &parents: parentsArray

and then ensureNamespace would be:

define: Namespace named: #SomeName &delegates: otherNamespaces

I think (I'm not sure) that this will allow us the flexibility to deal with 
the prototype and traits differently to allow for consistent re-loads of 
definitions.

Even so, when a prototype's clones are used in critical areas of the system, 
forwardTo: is not enough, since the time during which the load occurs will 
involve building up the set of roles that the object responds to. So there is 
a kind of transaction that would have to occur, OR addRolesFrom: would have 
to be invoked as well.

I'm kind of brainstorming here, and will have to test out the ideas 
thoroughly before I subject anyone to them.

Just FYI...