Smalltalk › Squeak › Squeak - Dev

Symbol>>capitalized?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

tblanchard

Symbol>>capitalized?

Squeak 3.7 ish -
I've got this meta model that stores attribute names as symbols.

I frequently derive labels from the attribute names and this often
ends up calling #capitalized on the symbol.

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.

Ralph Johnson

Re: Symbol>>capitalized?

> 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

tblanchard

Re: Symbol>>capitalized?

That sounds like a fine idea - I'll definitely continue to check it out.

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.

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
>

Terry Raymond-2

RE: Symbol>>capitalized?

In reply to this post by tblanchard

I would not recommend this. Normally, one would expect
that a transformation like #capitalized would return an
object of the same class. It would make more sense to
define #asCapitalizedString and change the code to use it.

Terry

===========================================================
Terry Raymond Smalltalk Professional Debug Package
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI 02878
(401) 624-4517 [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================

> -----Original Message-----
> From: [hidden email] [mailto:squeak-dev-
> [hidden email]] On Behalf Of Todd Blanchard
> Sent: Monday, January 01, 2007 7:05 PM
> To: The general-purpose Squeak developers list
> Subject: Symbol>>capitalized?
>
> Squeak 3.7 ish -
> I've got this meta model that stores attribute names as symbols.
>
> I frequently derive labels from the attribute names and this often
> ends up calling #capitalized on the symbol.
>
> 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.

Lex Spoon

testing system changes (was Re: Symbol>>capitalized?)

In reply to this post by Ralph Johnson

"Ralph Johnson" <[hidden email]> writes:
> 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.

As an aside, having a public package universe can provide more input
to these decisions. The idea is, packages include self tests, and you
have a package universe listing the packages that you want to continue
to support. Then, whenever you are considering a change, you can make
it locally and then run all of the packages' self tests to see if
anything broke.

There are a few aspects to this approach to keep in mind. One is that
you need a way to associate tests and packages. Whereas Scala uses
the filesystem for this [1], Squeak could use a registry object.

Second, you have to have a list of packages that you care about. A
package universe works can itself be such a list. SqueakMap also have
version tags that you can use, although for some reason these tags are
not always up to date. Whatever you do, though, you have to have SOME
kind of list of relevant packages. How to develope that list is a
fascinating question.

-Lex

[1] From http://permalink.gmane.org/gmane.comp.lang.scala/2894 :

To register a self test, the package should include a file whose
name is misc/sbaz-testall/tests/package-name, where package-name
is the name of the package with a self test. The contents of the
file should be a single line with the name of the object or class
holding the self test.

Andreas.Raab

Re: Symbol>>capitalized?

In reply to this post by tblanchard

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
>>
>
>
>

Marcel Weiher

Re: Symbol>>capitalized?

In reply to this post by tblanchard

On Jan 1, 2007, at 16:04 , Todd Blanchard 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

How about the following:

capitalizedString
^self asString capitalized

capitalized
^ self capitalizedString asSymbol

?

Marcel