On Thu, Nov 20, 2008 at 9:27 AM, Craig Latta <craig at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20081121/d2834c99/attachment.htm