I'm thinking a significant part of the problem of namespaces, version control, package loading and image release compatibility is that many versions of methods and classes can exist in the wild but the names do not include any information about their uniqueness. So when you load something it may stomp on methods that are still required in their previous incarnation for something else to work.
Possible solution:
- every entity and version of that entity for any image be assigned at creation/modification time a globally unique id that stays with that incarnation of the entity forever. So then whenever a package is loaded with whatever new versions it contains, it does not indiscriminately stomp on previous stuff, and everything else keeps working with the older versions as before, unless it is explicitly desired to move to newer versions. Multiple copies of classes and methods could then exist and be used side by side with the same names in the image since messages are sent to their unique identifiers, not just their name which is incomplete since it contains no version info.
Of course tools within the image would be needed to manage the multiple existing unique entities with same names in order to easily upgrade and test previous working packages to using the latest versions, but the tools should allow easily going back and forth between versions along with testing until you are happy that the new works well enough and you could then clean out the old if desired.
Wait, isn't Spoon going to do this?
Ken G. Brown
On Sat, Jun 28, 2008 at 11:58:21AM -0600, Ken G. Brown wrote:
I'm thinking a significant part of the problem of namespaces, version control, package loading and image release compatibility is that many versions of methods and classes can exist in the wild but the names do not include any information about their uniqueness. So when you load something it may stomp on methods that are still required in their previous incarnation for something else to work.
Possible solution:
- every entity and version of that entity for any image be assigned at creation/modification time a globally unique id that stays with that incarnation of the entity forever. So then whenever a package is loaded with whatever new versions it contains, it does not indiscriminately stomp on previous stuff, and everything else keeps working with the older versions as before, unless it is explicitly desired to move to newer versions. Multiple copies of classes and methods could then exist and be used side by side with the same names in the image since messages are sent to their unique identifiers, not just their name which is incomplete since it contains no version info.
Of course tools within the image would be needed to manage the multiple existing unique entities with same names in order to easily upgrade and test previous working packages to using the latest versions, but the tools should allow easily going back and forth between versions along with testing until you are happy that the new works well enough and you could then clean out the old if desired.
Wait, isn't Spoon going to do this?
Yes, it does that, from what I have been told.
squeak-dev@lists.squeakfoundation.org
-
Craig Latta -
Ken G. Brown -
Matthew Fulmer