<br><br><div class="gmail_quote">On Thu, Nov 20, 2008 at 9:27 AM, Craig Latta <span dir="ltr">&lt;<a href="mailto:craig@netjam.org">craig@netjam.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Hi--<br>
<br>
 &nbsp; &nbsp; This is another call for feedback on the design of Naiad[1], a Smalltalk module system I&#39;m writing for Squeak as part of the Spoon project[2].</blockquote><div><br>Hi Craig.<br><br>I think the main reason people aren&#39;t commenting is because that&#39;s a lot of reading! <br>
<br>My thoughts are:<br><br>* Separating name and identity is a very, very good start. But obviously you realise this :-).<br><br>* Perhaps &quot;versions&quot; is a better name than &quot;editions&quot;? That&#39;s the name we&#39;re more familiar with.<br>
<br></div></div>* 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&#39;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?<br>
<br>* Does the system work if it can&#39;t contact the edit history object memory?<br><br>* 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?<br>
<br>* I assume a class now contains a ClassID and a collection of MethodIDs?<br><br>* 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?<br>
<br>* Limiting to 65,536 versions per author is going to create problems in 10 years time.<br><br>* Isn&#39;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?<br>
<br>* Are author UUIDs going to be able to be looked up to get email addresses and names somehow?<br><br>* Methods shouldn&#39;t have an author. The changes between methods versions/editions should have an author.<br><br>
I think you&#39;re taking the &quot;minimal memory usage&quot; idea too far. In my design for distributable packages, I&#39;ve made a couple of different design decisions:<br><br>* 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.<br>
<br>* I&#39;ve separated source from bytecodes. A Package object contains only structural information and bytecodes (or it will when I&#39;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.<br>
<br>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&#39;ll be interesting to see how it pans out.<br><br>I&#39;m not sure it&#39;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 &quot;change-shock&quot; in the community.<br>
<br>Gulik.<br><br>-- <br><a href="http://people.squeakfoundation.org/person/mikevdg">http://people.squeakfoundation.org/person/mikevdg</a><br><a href="http://gulik.pbwiki.com/">http://gulik.pbwiki.com/</a><br>