On Thu, Nov 20, 2008 at 9:27 AM, Craig Latta <craig@netjam.org> wrote:

Hi--

    This is another call for feedback on the design of Naiad[1], a Smalltalk module system I'm writing for Squeak as part of the Spoon project[2].

Hi Craig.

I think the main reason people aren't commenting is because that's a lot of reading!

My thoughts are:

* Separating name and identity is a very, very good start. But obviously you realise this :-).

* Perhaps "versions" is a better name than "editions"? That's the name we're more familiar with.

* Do we need to run two instances of Squeak to edit code, one for the current version and one for managing the edit history? I assume that's what you mean by needing two object memories. If so, is it intended for the edit history object memory to be a live central repository shared by developers?

* Does the system work if it can't contact the edit history object memory?

* What do your remote references look like? How stable are they? Do they rely on, e.g. IP address to find a remote object memory? If somebody changes IP, are the remote references still valid?

* I assume a class now contains a ClassID and a collection of MethodIDs?

* Why is ClassID so complex? Why not just assign each class a new UUID for each new version of that class, with authorship and versioning being metadata of that class?

* Limiting to 65,536 versions per author is going to create problems in 10 years time.

* Isn't having the author and version in the unique IDs going to cause conflict problems? What happens if the author is careless and ends up with two different versions of a method with the same unique identifier?

* Are author UUIDs going to be able to be looked up to get email addresses and names somehow?

* Methods shouldn't have an author. The changes between methods versions/editions should have an author.

I think you're taking the "minimal memory usage" idea too far. In my design for distributable packages, I've made a couple of different design decisions:

* Packages (cf: classes in Naiad) are immutable and copy-on-write. When a Package (containing classes and methods) is completed and ready for distribution, it is made read-only and assigned a new UUID. If somebody wants to modify that Package, they need to (deep-)copy it and assign it a new UUID. In an object memory with two versions of the same package loaded, the two packages would exist as near identical copies of each other. This is a waste of memory, sure, but memory is cheap and this scheme is much simpler than fiddling around with sharing different class and method versions in two similar packages.

* I've separated source from bytecodes. A Package object contains only structural information and bytecodes (or it will when I've implemented that). The source code is managed by a completely separate pluggable system over which a compiler is run to produce a Package object. In this way, people have a lot more flexibility to change the way that source code is managed. Authorship and versioning information is all moved out to the source code managing system.

My opinion in general is that Naiad is a very interesting system. It certainly solves a lot of problems in Squeak, and adds new functionality. It'll be interesting to see how it pans out.

I'm not sure it's a good idea to propose an unstable system as the next version of Squeak though. I would prefer that the system is first stable, tested and used before it is pushed into the community. I would be wary of causing a "change-shock" in the community.

Gulik.

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