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

[Frank Shearar]

On 24 September 2014 09:16, Torsten Bergmann <astares at 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