[squeak-dev] namespaces, version control, package loading and image release compatibility

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:
Yes, it does that, from what I have been told.

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/

My Package/Namespaces architecture was designed to solve the problems of namespaces, version control, atomic package loading, and package interdependence. In theory at least, a loaded package will run in exactly the same environment it was written and tested in, even to the extent of automatically loading that environment into the image if need be.

These are unstructured braindumps of what I've been working on:
http://gulik.pbwiki.com/Namespaces
http://gulik.pbwiki.com/Packages

I'm now writing tests and fixing up bugs in the core code. An alpha release will be made "soon".

I'm designing these Namespaces for a fork of Squeak called SecureSqueak which is designed to run untrusted code in a secure sandbox. It is not intended for general use in Squeak.

Gulik.


--
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/

Very interesting and very useful.
A dream come true?
Keep up the good work!
--Trygve

On 29.06.2008 23:57, Michael van der Gulik wrote:

On Sun, Jun 29, 2008 at 5:58 AM, Ken G. Brown <[hidden email]> 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.

My Package/Namespaces architecture was designed to solve the problems of namespaces, version control, atomic package loading, and package interdependence. In theory at least, a loaded package will run in exactly the same environment it was written and tested in, even to the extent of automatically loading that environment into the image if need be.

These are unstructured braindumps of what I've been working on:
http://gulik.pbwiki.com/Namespaces
http://gulik.pbwiki.com/Packages

I'm now writing tests and fixing up bugs in the core code. An alpha release will be made "soon".

I'm designing these Namespaces for a fork of Squeak called SecureSqueak which is designed to run untrusted code in a secure sandbox. It is not intended for general use in Squeak.

Gulik.


--
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/

 > Wait, isn't Spoon going to do this?

      Yes.


-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]