SM final tweaks (was Re: Trouble getting SqueakMap to work)

Martin Wirblat sql.mawi at
Thu Jan 29 09:33:06 UTC 2004

Avi Bryant <avi at> wrote on 29.01.2004 00:02:44:
>On Jan 28, 2004, at 2:32 PM, goran.krampe at wrote:
>> So the idea is to... add this "speaking UUID" as a field in 
>> SMPackage? Which is generated when the package is registered I 
>> assume. 
>> First - this "speaking UUID" would still not make packages 
>> renameable. Secondly - since this is so, the extra number at the 
>> end is hardly necessary since SM actually enforces the package name 
>> to be unique! 
>> So actually - what does this mean? What would happen if we simply 
>> used the package name (haven't looked at your code) with tricky 
>> chars removed
>> as shown above and perhaps also changed into lowercase (are all
>> filesystems case sensitive?) and truncated at 31 chars?
>> Well, theoretically the removal of tricky chars/truncation etc could
>> make two packages end up with the same name.
>I think you're misunderstanding.  Let me rephrase (my understanding 
>of) the proposal:
>Currently, to generate a new unique ID for a package you use Squeak's 
>UUID class, which basically gives you a large random number.
>What if, instead, you used a derivation of the original package name 
>(whatever it is first registered with), truncated and with tricky 
>characters removed, and with some extra numbers at the end to ensure 
>This isn't a new field, or a new concept, or something that in any 
>way changes any of the semantics of SM.  It's simply a new algorithm 
>for generating the UUID for a package that happens to have the nice 
>property that a human, looking at a UUID, may be able to guess which 
>package it belongs to (although in some cases, especially after 
>package renames, they may not be able to guess with 100% certainty).
>This sounds like a pretty good idea to me.

Yes, exactly that is the idea, a new algorithm for generating a UUID - 
the speaking UID. 

Some thoughts about lower/uppercase: 
I have written this method so that it generates both upper- and 
lowercase. If for some reason it is necessary to resort to only one 
of that, you can simply convert this UID with e.g. asLowercase. This 
only moderately increases the probability of a name clash ( look at 
comment of method ). 

For SM it may be appropriate to do so at the 'very last moment', when 
it comes to database storage or retrieval. The package itself would 
have the full ( upper + lower case ) UID, path names of filessystems 
would etc.

The idea is that if there is an 'obscure communication channel', which 
flattens the UID to say lowercase, SM is nonetheless able to tell 
which package is associated with that UID, simply because it 
registered it under UID asLowercase. The name clash probability would 
be only somewhat increased, and the readability for humans preserved. 

All modern filesystems I know of are preserving the capitalization 
info, but some ( e.g. all Windows fs's ) do not use it. Internally 
they convert names 'asLowercase'. A SM-cache on Windows would have a 
higher name clash probability than one on UNIX, but both are happy 
with mixed capitalization. 


More information about the Squeak-dev mailing list