[Vm-dev] re: deployment components (was "The Dilemma: Building a Futuristic GUI for Ephestos")

[Torsten Bergmann]

Craig Latta wrote:
>Right, there's no need for anyone to use UUIDs when referring to
>classes in Smalltalk expressions. 

Yes, exactly this. We still use regular names for the classes - but for the tools
they have a distinguishable ID. 
Best is to use a UUID for the ID as it is unique from the beginning. So if you 
create a class "Foo" and I create one both are unqique by ID - even when using 
the same name.

The "rest" is implemeting tooling support. When you write "Foo" in a workspace 
then the workspace either already has a naming context to resolve the name (see [1]
or could provide you with a selection if there is more than one. Internally you could 
bind to the right class by using the ID.

I hate prefixing the classes as we now do, I want to name the classes "Instruction"
not "IRInstruction" in Opal or "AJInstruction" in AsmJIT, especially since "IR" and "AJ" 
do not really tell you anything. Smalltalk names should be understandable. Additionally
we should have meaningfull (and also unique) names also for namespaces.

Also the current three/two letter prefixing of classes that is used in Squeak or Pharo 
only scales well for small communities...

When there are things I like in Java then it is the fact to use reverse domains
for namespaces. It is easy, understandable and I could also easily check if there
is a web location.

This way a namespace "org.apache.maven" gives you something meaningful, I can even
visit http://maven.apache.org/. Allows the community to easily scale with thousands of 
classes without having clashes.

Think of "org.pharo.asmjit.Instruction" vs "org.pharo.opal.Instruction" 

So you additionally need better and meaningful namespaces THAT SCALE AND ARE EASY TO UNDERSTAND
combined with real packages (as objects, as Pharo already has). 

Then we also need ABIA (Around, beginner, inner, after messages), multiple method 
categories, selector namespaces, possibility for visibility (like private methods, see [2]), 
unified annotations for classes/methods/variables and a few other ingredients from my 
personal wishlist and it may shape a different new future...

The interesting part is not to add all kind of stuff to Smalltalk - the interesting
part is what is the most minimalistic system to allow for something extensible 
and still flexible (even within the meta-system) so that one can bootstrap things on top.

Bye
T. 
 
[1] http://vimeo.com/75391990
[2] http://smalltalkhub.com/#!/~CamilleTeruel/PrivateMethods