On 24 September 2014 09:16, Torsten Bergmann <astares@gmx.de> wrote:
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 problem I have with UUIDs is that, in a distributed setting, you need to rely on everyone to generate UUIDs correctly. Now IF everyone implements UUID generation correctly, and IF everyone plays the game in good faith, you will almost certainly not get a UUID clash. But when you say your code depends on package/class/object/method with guid SOME_GUID, and I as a bad actor inject my own class with guid SOME_GUID, how are you to know that you've just been 0wned? Wouldn't it be better, instead of using a key-value store (key K maps to value V), we have a store that uses function_of(V) maps to value V? Like in git: a commit is uniquely identified by its hash and, because the hash is a checksum, you can't - short of engineering a SHA-1 collision (good luck with that) - forge part of the system.
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.
Yes, that "rest" is most of the work. But you know this because of the scare quotes :)
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).
We already have this, or the basis at least, in Squeak in the form of Environments.
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...
Squeak hasn't done this yet, but it should be possible to use Environments to implement selector namespaces. We haven't done it yet because Colin Putney's been really busy lately, and no one else has had the time/energy to Just Do It. And if you have selector namespaces, you have private methods, don't you? frank
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