Remove trailing spaces of aString

Hello

I use Squeak 4.3, Update 11860.

I want to remove the trailing spaces and or tabs and LF of a String

something like
'abc
'

should just be
'abc'.

If I remember  that there was a method in class String to something
like this. Is this correct?
Is there a package with additional String convenience methods?

Thank you for the answer in advance
--Hannes
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

In a Workspace, try:

'abc    ' trimRight

There's also trimLeft and a trimBoth. You can browse the String class
to see them. You can also see the code in there which gives a hint as
to how easy it is to modify for different character.

===Blake===

On Fri, Apr 27, 2012 at 8:27 AM, H. Hirzel <[hidden email]> wrote: _______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Blake,

This is actually the problem

'abc    ' trimRight

does not work in

4.3, Update 11860  (= the version in the one-click download from
http://ftp.squeak.org/4.3/Squeak-4.3-All-in-One.zip )

"unknown selector"

Which version do you use?

--Hannes

On 4/27/12, blake <[hidden email]> wrote: _______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Am 2012-04-27 um 17:27 schrieb H. Hirzel:

you probably want

'abc ' withoutTrailingBlanks

You can find that method by evaluating or printing

MethodFinder methodFor: { {'abc  '} . 'abc' }
(a list with arguments  {'abc '}  and  an expected result ( 'abc' ))

HTH

Best
        -Tobias
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Sorry, Hannes,

I happened to have Pharo up right then so I used that. Not thrilled
they have different methods for this.

===Blake===

On Fri, Apr 27, 2012 at 12:28 PM, H. Hirzel <[hidden email]> wrote: _______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Thank you Tobias for answer
  'abc ' withoutTrailingBlanks    "Squeak"

Blake for pointing out the Pharo method

   ''abc  '   trimRight    "Pharo"


The reminder about MethodFinder is useful.
MethodFinder methodFor: { {'abc  '} . 'abc' }

--Hannes

On 4/27/12, blake <[hidden email]> wrote: _______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

I'll note that 'trimRight' is a poorly considered change in Pharo.
A name like 'withoutTrailingBlanks' implies making a copy of the
original string, but with the trailing blanks removed. That is of
course exactly what the method is supposed to do. But the name
'trimRight' implies an operation on the receiver itself, as in
"trim something from the right of this string". This is not at all
what you want, and it is not what the method actually does either.

Smalltalk makes it very easy to make changes like this, but this
also makes it quite important to think about the meaning of the
names used for your methods and classes.

It is also important to use some common sense when changing the
names of methods that other people may be using. It is often the
case that you will not know about all of the people who may be
using your classes and methods, so changing their names carelessly
can have unintended side effects. This was the case for me with
the 'trimRight' name change, which caused a number of annoying
problems for a package that I maintain.

Dave


On Fri, Apr 27, 2012 at 11:20:26PM +0200, H. Hirzel wrote: _______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

On 4/28/12, David T. Lewis <[hidden email]> wrote:
Thank you for this clarification, Dave.
A follow up question: How did you deal with this to make code work in
Pharo and Squeak?
Which coding pattern did you use?

--Hannes

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

On Sat, Apr 28, 2012 at 10:14:04AM +0200, H. Hirzel wrote:
There are a couple of approaches that can be used. I have not
yet addressed the problem with trimRight (which affects CommandShell
when running under the latest Pharo). I'm not sure that there are
any "good" ways to address the issue, but here are a couple of
approaches that would work.

One approach is to just re-implement the needed functionality as
a private method in your own package, so the new method might
be something like MyClass>>withBlanksTrimmed: aString. This is
a dangerous approach in this case though, because it requires your
private method to know something about strings and characters, and
it might break at some time in the future when someone makes an
improvement to String, or when someone tries to use MyClass with
a string encoded with Arabic characters.

A second approach is to use a runtime test to figure out what
selector to use. In this case, if we know that most imags implement
#withBlanksTrimmed, but one variant has decided to use #trimRight
instead, we can do something like this:

        myString := 'this is a test    '.
        myStringWithoutTheSpaces :=
                (myString respondsTo: #trimRight)
                        ifTrue: [ "this is probably a recent Pharo image"
                                myString perform: #trimRight ]
                        ifFalse: [ "this is how it works for everybody else "
                                myString perform: #withBlanksTrimmed]

Note that #perform is used to send the message. This allows you
to compile the method on either Squeak or Pharo regardless of whether
#trimRight is implemented in your image.

A similar approach can be used for classes, so you can write things
like this:

        Smalltalk at: #FooClass ifPresent: [ :fooClass | fooClass new ]

If you are writing a large package that needs to deal with issues like
this, it is a good idea to isolate the differences in a compatability
layer that permits your package to run on various images, and localizes
the differences in the compatibility package. An excellent example of
this is the Grease package that is used with Seaside (and others) to
allow Seaside to run on a wide range of platforms and images.

Of course the best approach of all is to not make unnecessary changes
to well-known method names in the first place. That avoids the problem
of a minor "improvement" in a core package leading to compatibility
hacks in the packages that depend on it. But often you will have no
control over this, so the solution is to work around the problem as
described above, or rely on a compatability layer such as Grease.

Dave
 
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners