[squeak-dev] The Trunk: EToys-topa.121.mcz

Chris Muller asqueaker at gmail.com
Fri Apr 3 01:44:05 UTC 2015


>>>>>> I prefer to use Symbols instead of Strings for class names, because they make it easier to find potential users of the class.
>>>>
>>>> +1
>>>>
>>>>> yes, but #hasClassNamed: is a String protocol.
>>>>
>>>> A Symbol is a String.  Many (if not all) existing users of
>>>> hasClassNamed: pass Symbols (a special kind of String).
>>>
>>> I don't want to rely on that.
>>> Symbols being Strings is an implementation detail.
>>
>> Symbols logically ARE Strings, regardless of implementation.  They're
>> a series of characters just canonicalized.  Its only the
>> canonicalization that's implementation-specific, not equality or type
>> testing..
>
> Nope. The idea of a symbol is (IMHO, admittedly) broader than
> just canonicalized Strings. If it where, I would call it InternedString
> or CanonicalizedString. Symbols are unique human readable identifiers.
>
> See Prolog, where the concept is called Atoms. There is no conceptual
> differences. Yet, Prolog atoms do not remotely compare to interned strings.

I may be missing your point -- Prolog and Gemstone and Ruby and Lisp
all have different semantics for many types not just Symbols.

If you want to try to match an ethereal notion of some Squeak types to
other languages, TileMorphTest is not quite the best place to start is
it?  ;-)  Such a daunting mission would need to be thought out and
planned at a system-wide level..

In the meantime, what about consistency of the code within the image?
And about Levente's point about tool support?

>>> Looking at the broader picture, in GemStone, in fact
>>> a Symbol is not a String.
>>
>> Object name  "#Object"  <---- a Symbol.
>>
>> So why do you say #hasClassNamed: a "String protocol" instead of a
>> "Symbol protocol"?
>
> See #classOrTraitNamed: (which is called by #classNamed:)
>
> classOrTraitNamed: aString
>         "aString is either a class or trait name or a class or trait name followed by ' class' or 'classTrait' respectively.
>         Answer the class or metaclass it names."
>
> and
>
> hasClassNamed: aString
>         "Answer whether there is a class of the given name, but don't intern aString if it's not alrady interned.  4/29/96 sw"

Class #name's are Squeak Symbol's, which are just as capable of (and,
responsible for) naming something as a String is.  The API's above
support Strings for *convenience* (in case you got it from a file or
something, so you don't have to send #asSymbol first).

When you create a new class, you use a Symbol to define the #name, don't you?

Object subclass: #MyObject
     instanceVariableNames: ''
     classVariableNames: ''
     poolDictionaries: ''
     category: 'MyApp'

Why would Smalltalk be designed to use Symbols for the class
'creating' API and Strings for its accessing API?  It makes no sense
and renders the tools impotent.  You are brilliant Tobias but I think
we don't understand your reasoning this time..


More information about the Squeak-dev mailing list