Squeak as Linux and other threads

Martin Wirblat sql.mawi at t-link.de
Thu May 22 19:40:23 UTC 2003


Hi Göran
>> >SharedStreams-gh
>> 
>> I must say if we really use PackageName_GlobalName as 'simple name 
>> spaces' I dislike this idea. PackageName should be chosen as you 
>> said: short, meaningful, without spaces, just like other Smalltalk 
>> identifiers ( we are going to code with them = we have to speak 
>> them ). 
>>  
>> BTW, what if not the package rather than the author wants to change 
>> his name? :) 
>
>I am not sure what you are saying here. You dislike the idea - but 
>what did you want instead? 

'SharedStreams' instead of 'SharedStreams-gh'. If we have to write 
such identifiers in code the '-gh' gives no useful information about 
the variable ( SharedStreams_GlobalVarName ) so it would be only a 
distraction for the programmer. I think these linguistic differences 
are very important, they are summing up if neglected. 

>What I want to have is company/group/personal SM servers. That can 
>work offline. I want to be able to have "local" packages that noone 
>sees until I push them upwards to a chosen master. It is not 
>farfetched - when you think about it there are quite few places in 
>which conflicts may occur.

Ok, agreed, not farfetched. But in the moment of publication a central 
nameserver could verify that the chosen name is unique and register 
the new one. This should be even simpler, than having this hierarchy 
of servers afterwards checking on the uniqueness and perhaps requiring 
a change of the name ( version with no sig-namespace ). 

Compared with the sig-namespace version I would strongly vote for 
clean variable names and the central name server. Having an 
infrastructure of a server hierarchy an additional name checking 
authority should not make much difference. 

In a way the sig-namespace must be checked too - who assures that no 
one uses a sig privately that no one else uses? Look at todays 
situation, there is just a webpage, and it is by no means complete. 

regards,
 Martin



More information about the Squeak-dev mailing list