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