Hey

On 03.04.2015, at 17:25, Levente Uzonyi <leves at elte.hu> wrote:

> On Fri, 3 Apr 2015, Tobias Pape wrote:
> 
>> 
>> On 03.04.2015, at 01:00, Chris Muller <asqueaker at gmail.com> wrote:
>> 
>>> On Thu, Apr 2, 2015 at 5:52 PM, Tobias Pape <Das.Linux at gmx.de> wrote:
>>>> Hi,
>>>> 
>>>> On 03.04.2015, at 00:32, Levente Uzonyi <leves at elte.hu> wrote:
>>>> 
>>>>> 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.
>> Looking at the broader picture, in GemStone, in fact
>> a Symbol is not a String.
> 
> This code is not intended to be portable to other dialects, so IMHO it's fine to use Symbols as Strings. If we ever decide to make Symbols to not be Strings anymore, then we'll have to scan the image (and external packages) anyway.

We have several things here:

1. Symbols vs. Strings
2. How to reference a class indirectly
3. Consistent idiomatic code

My code was because of a mixture of all three. I started with 2, thought about 3 and ended
up with #hasClassNamed:, and due to 1 I used the code as is.
Yes, I'll change it.

But let me explain. I try write code that should be read.
So, #hasClassNamed:/#classNamed: is undoubtedly more intention-revealing than
the pseudo-Dictionary API. 
  Now I saw that #hasClassNamed is a String API (it really is) and remembered
that, while I can treat strings and symbols as same in Squeak, it is unportable[1]
and I don't want to write unportable code unless I have to or it is reallly convenient.

Yes, it is actually fine to write the convenient code in this place. (I'll change it :) But
probably we have to think about the String/Symbol thing once again. If we perpetuate this
implicit assumption throughout the core, I think we only encourage people to write
unportable code, which I think would be really sad.



[1]: ANSIs only requirement to both String and Symbol is that they conform to the <readableString> protocol, ie,
     they both answer correctly to #asString and #asSymbol. Really, I looked it up.