Squeak and Namespaces

Klaus D. Witzel klaus.witzel at cobss.com
Thu Nov 30 09:49:43 UTC 2006


Hi Keith,

on Thu, 30 Nov 2006 03:33:42 +0100, you wrote:
> Klaus wrote:
>> No, this was not my idea. The compiler reduces the #>~ message symbol:
>>
>>  (A >~ B) "results in"
>>  (Association key: #B value: B) "which is a component of A"
>>
>> For namespace maintenance:
>>
>>  (A >~ B) moveToNamespace: C. "next line still refers to same B"
>>  (A >~ B) namespace shallowCopy moveToNamespace: D.
>>  (C >~ B) = (D >~ B) "true"
>>
>> /Klaus
> So would it be possible to
>
> a) remove the 'bug' which allows ':' in Class names, and

Sure. Get rid of it.

> b) allow the binary operator shown above to be '::'?

In principle: yes. Except for #Aselector: and Aclass, which can be  
mistaken (next line is a bug) for

  Aselector::Aclass

> #>~ seems rather naff #>> would make some sense to me but is used by  
> Integer for shifting, so I guess it would not be available.

I won't care as long as colons are explicitly reserved for the argument  
concept. From the GOF designers point of view, *either* a selector has  
special character(s) *or* the argument(s) are delimited by a special  
character (colon for the latter) - and no whitespace allowed, like in  
negative examples (3 + = 4) and (key : value).

This "special character *or colon* accompanies *every* argument position"  
message of Smalltalk was always evangelistic clear to me. We don't have  
#(( or #[[ or #^^ or #__ or #.. and I hope the same for the #:: symbol.

/Klaus

> cheers
>
> Keith




More information about the Squeak-dev mailing list