Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!purdue!haven.umd.edu!news.ums.edu!news.bbnplanet.com!cpk-news-hub1.bbnplanet.com!portc02.blue.aol.com!howland.erols.net!news.mathworks.com!uunet!in1.uu.net!uucp5.uu.net!world!carlg
From: carlg@world.std.com (Carl E Gundel)
Subject: Re: [VSE] #asNumber and #trimBlanks
Message-ID: <E32v2s.IoE@world.std.com>
Organization: The World, Public Access Internet, Brookline, MA
X-Newsreader: TIN [version 1.2 PL2]
References: <19961226235900.SAA01639@ladder01.news.aol.com>
Date: Fri, 27 Dec 1996 15:01:40 GMT
Lines: 72

Dogmat (dogmat@aol.com) wrote:
: In VSE, the following code:
: ' 123' asNumber    "Note the whiteSpace prefix"
: returns 0 as the result.

: I can understand the reasons for this, but I don't like it. I want the 
: number 123 returned as the result. I don't want to have to code all my 
: messages as:
: aString trimBlanks asNumber
: So I am thinking about modifying the String class method #fromString: to 
: ignore whiteSpace. This is definitely brain surgery on self. I don't like 
: this either. Damm.

I would recommend writing your own asNumber method.  This would eliminate 
any trouble that you would encounter because some mechanism in Smalltalk 
depends on the behavior of asNumber being what it is.  Call your method 
#myAsNumber or something similar.  It is (as you noted) not usually a 
good idea to modify base methods.


: This led me to look at the String #trimBlanks message, shown below:
: {code omitted}
: Note that even if there are NO leading or trailing blanks, the String
: always returns a copy. Isn't this wasteful? Why not just return self?

There are times when I wish (for performance reasons) that Strings could 
return a resized self.

The positive side is that operations like #trimBlanks are nondestructive.  
It may seem a waste to keep the string we are trimming, but then if it 
didn't work that way, and we wanted to keep the original string, we would 
have to write extra code to do so.

   originalString := aString copy.
   trimmedString := aString trimBlanks.

Additionally, Smalltalk strings are fixed in size, so you can't just 
shorten the receiver of #trimBlanks.  You could write your own string 
class to add resizable strings (call it ResizableString).  You would 
still need to use class String in your literals though and convert them 
to resizable strings like so:

   myString := 'This is a test' asResizableString.

or maybe

   myString := 'This is a test' resizable.

This of course introduces the same kind of waste, as we throw away the 
string we are copying from to make the resizable string.  But if we will 
use a ResizableString in a tight loop many times then it might be worth 
it, if our ResizableString is implemented efficiently enough.

Ultimately to achieve a goal of less waste, any implementation of 
ResizableString would need to avoid creation of new objects and 
discarding of old ones in the process of doing things like trimming 
blanks.

As an aside, I'll add that base code in Smalltalk tends to be highly 
optimized.  When profiling my own code I usually reap a great 
performance gain, but I've never been able to noticably improve the 
performance of the Smalltalk base objects (at least with Digitalk's 
products).

Regards,

Carl
-- 
------------------------------------------------------------------
 Carl Gundel  carlg@world.std.com  Shoptalk Systems  508-872-5315
 author of Liberty BASIC, a 1996 PC Magazine Awards Finalist!
 http://world.std.com/~carlg/basic.html
