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
|