Hi Eliot!
Torsten writes:
Classes with UUIDs to allow for side by side loading/migration and an extensible meta-scheme as this is where Smalltalk is still the hero of all and metaprogramming will be our future.
You respond:
So so far I have pinning. But I'd love to hear more detail on sandboxing. I'm not sure about UUIDs. What about other mechanisms, namespaces, ClassBoxes? UUID sounds too much like an implementation to me. No one is proposing qualifying class names with UUIDs (Array:c5c09212-0c7d-44f3-81b7-18ae5d7f14d9 new: 5 ????). How about reiterating this more abstractly?
Right, there's no need for anyone to use UUIDs when referring to classes in Smalltalk expressions. We can keep using class names as we always have. Instead, we can do the following:
- Add an ID field to each class.
- Make each class responsible for its own name literal. The "name" field of each class would hold the method literal used by methods that refer to that class, rather than just a name key into the traditional system dictionary.
This allows each class to have any name. When a developer attempts to compile source that refers to a particular class name, the system can present a list of all the classes with that name from which to choose. To aid in the decision, the system can present additional information, such as author, release date, module membership, etc. When displaying method source after compilation, the system can emphasize class names which correspond to multiple classes, and provide quick means for getting at that additional information.
We could keep that information in a live memory of objects describing edits made to the system, with which we can interact via remote messaging. Let's call it a history memory. Like the traditional changes/sources system, it could record the history of our development activity, but with all the reflective power of an object system for answering our queries (and synchronizing with other systems on our behalf).
This history memory could supplant the traditional system dictionary and changes/sources files. The key to making this practical is having a minimal object memory and a module system with which to grow it.
I've done all this. Will you collaborate with me?
thanks!
-C
[1] http://thiscontext.com/a-detailed-naiad-description
(I'm currently working on a GitHub-based installer. It interacts with GitHub's web services API, reminiscent of the WebDAV support I wrote for interacting with the live system from Your Favorite Text Editor.)
-- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)