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
|