Todd Blanchard wrote:
> I did spot a case or two where the point was to ultimately generate a 
> symbol, but capitalized was an intermediate result so you ended up 
> interning a bunch of intermediate results that were never used.

Just glancing over a few places it's pretty obvious that at least 
CategoryViewer>>getterTilesFor:type: and SlotInformation class>>type and 
StandardScriptingSystem>>colorForType: all require #capitalized to 
return symbols, not strings.

Cheers,
   - Andreas



> 
> On Jan 2, 2007, at 2:13 AM, Ralph Johnson wrote:
> 
>>> I generally figure any string manipulation on a symbol results in a
>>> string but Symbol>>capitalized is implemented as
>>>
>>> capitalized
>>>
>>>         ^self asString capitalized asSymbol
>>>
>>> I found this while watching the process browser running a lengthy
>>> script in the background and found about 80% of time was spent in
>>> WeakSet scanFor:
>>>
>>> I did a search of the image and couldn't find a single instance of
>>> sending capitalized to a symbol where the caller was going to use it
>>> as a symbol rather than a string.
>>>
>>> So, in the name of performance, I vote to nuke this method or change
>>> it to just return a string.
>>
>> I would be much more convinced if you had said "I've been making this
>> change to all my programs for the past year and have never ran into
>> any difficulty because of it."
>>
>> There isn't much risk if you make that change to your image because
>> you will remember that you made the change and if you run into a
>> problem because of it, you'll probably catch it right away.  However,
>> if we make the change to the standard image then it might change the
>> behavior of someone's application who doesn't know the change was made
>> and so will have a hard time figuring out what happened.
>>
>> I suggest you make that change in all your programs and report back
>> next year.  In fact, I encourage lots of people to make that change.
>> Then, when we have a debate in a year we can have testimonials like "I
>> tried it and everything was fine" or "I tried it and it broke XXX".
>> That would be the right time to make the change.  Or not.
>>
>> Performance improvements are good, and we want to be continually
>> making them.  Hoever, they are rarely critical, and it is better to
>> check them out carefully before making them.
>>
>> -Ralph Johnson
>>
> 
> 
>