[Vm-dev] re: deployment components (was "The Dilemma: Building a
Futuristic GUI for Ephestos")
craig at netjam.org
Fri Sep 19 20:20:32 UTC 2014
> 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.
> 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?
(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.)
+31 6 2757 7177 (SMS ok)
+ 1 415 287 3547 (no SMS)
More information about the Vm-dev