Smalltalk › Squeak › Squeak - Dev

[Squeak 4.1] Collections: Failure of Concatenation Operator

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Peter Kenny

[Squeak 4.1] Collections: Failure of Concatenation Operator

Hello All

I'm not sure if this is the right place to raise this, but at least this is
an active group, so perhaps someone will give me a steer if it is not. I
have mentioned it in Mantis, but the message numbers there make it seem that
I am the only person posting there and nobody seems to be reading.

Squeak 4.1 has a method String>>, which does not exist in earlier Squeaks.
From the method comment, it is there to allow a concatenation of a String
with something which is not a collection; the example quoted in the comment
is:
Transcript cr; show: 'The value is: ', 3.
which is illegal in earlier Squeaks, in Pharo, in Dolphin and in Smalltalk/X
(I haven't checked others). The problem is that allowing it causes a failure
in concatenating a string to an array of characters; in my case the
construct was ('/', Character separators), which was used to generate a
collection of terminators for String>>findTokens:. As a result, an
established Squeak package (Todd Blanchard's HTML and CSS Validating Parser)
does not work 'as is' on Squeak 4.1.

I have discussed this in Mantis, and proposed two solutions: either get rid
of String>>, (because what it allows should be illegal) or modify it so that
the case where the argument is a kind of SequenceableCollection is dealt
with as in earlier Squeaks.

I have checked the latest Squeak 4.2 alpha that I can find, and the problem
is still there. I have gone through the list of posts in this group which
mention collections, and I cannot find a modification affecting this. If it
has been dealt with, my apologies. If not, it seems a good idea to look at
it before Squeak 4.2 is released.

My Mantis posts can be found at
http://bugs.squeak.org/view.php?id=7564

--
Best wishes

Peter Kenny

David T. Lewis

Re: [Squeak 4.1] Collections: Failure of Concatenation Operator

On Mon, Oct 25, 2010 at 02:51:48PM -0700, Peter Kenny wrote:

>
> Hello All
>
> I'm not sure if this is the right place to raise this, but at least this is
> an active group, so perhaps someone will give me a steer if it is not. I
> have mentioned it in Mantis, but the message numbers there make it seem that
> I am the only person posting there and nobody seems to be reading.
>
> Squeak 4.1 has a method String>>, which does not exist in earlier Squeaks.
> >From the method comment, it is there to allow a concatenation of a String
> with something which is not a collection; the example quoted in the comment
> is:
> Transcript cr; show: 'The value is: ', 3.
> which is illegal in earlier Squeaks, in Pharo, in Dolphin and in Smalltalk/X
> (I haven't checked others). The problem is that allowing it causes a failure
> in concatenating a string to an array of characters; in my case the
> construct was ('/', Character separators), which was used to generate a
> collection of terminators for String>>findTokens:. As a result, an
> established Squeak package (Todd Blanchard's HTML and CSS Validating Parser)
> does not work 'as is' on Squeak 4.1.
>
> I have discussed this in Mantis, and proposed two solutions: either get rid
> of String>>, (because what it allows should be illegal) or modify it so that
> the case where the argument is a kind of SequenceableCollection is dealt
> with as in earlier Squeaks.
>
> I have checked the latest Squeak 4.2 alpha that I can find, and the problem
> is still there. I have gone through the list of posts in this group which
> mention collections, and I cannot find a modification affecting this. If it
> has been dealt with, my apologies. If not, it seems a good idea to look at
> it before Squeak 4.2 is released.
>
> My Mantis posts can be found at
> http://bugs.squeak.org/view.php?id=7564
>

It's definitely the right place to discuss things like this, and I see
that Andreas has added a comment to the bug report. You have a good point
about breaking an existing package, but in this case IMHO it is something
that would best be addressed in the external package. Even though earlier
versions of Squeak behaved differently, it seems most reasonable to expect
that if you have a string and append something to it, then the result should
be something resembling a string. So the new >>, operator makes good sense
even if it does cause problems for an existing package.

I'm not sure if Todd is activitely maintaining this package, but a
note to him might be in order.

Dave

Peter Kenny

Re: [Squeak 4.1] Collections: Failure of Concatenation Operator

David T. Lewis wrote

Even though earlier
versions of Squeak behaved differently, it seems most reasonable to expect
that if you have a string and append something to it, then the result should
be something resembling a string. So the new >>, operator makes good sense
even if it does cause problems for an existing package.

I'm not sure if Todd is activitely maintaining this package, but a
note to him might be in order.

Dave

Andreas has now fixed this by changing how 'Character separators' works. I agree with you that the result of concatenation to a string should resemble a string (or even *be* a string). The question is whether the something concatenated - the argument - should resemble a string, at least to the extent of being a kind of sequenceable collection. If it is, then the method as in earlier Squeaks is surely correct. If it is not, maybe we can assume that the printString is what is required, but it seems safer to me to fail it and force the user to be more explicit.

I'm not trying to be an agent provocateur, and indeed I do not expect to use Squeak much, so don't waste time on an answer unless you feel strongly.

Peter Kenny

Göran Krampe

Re: [Squeak 4.1] Collections: Failure of Concatenation Operator

Hi all!

On 10/26/2010 06:41 PM, Peter Kenny wrote:
> as in earlier Squeaks is surely correct. If it is not, maybe we can assume
> that the printString is what is required, but it seems safer to me to fail
> it and force the user to be more explicit.

Having spent last months working in a large Perl system I feel much
stronger about explicitness being a GOOD thing. More than once did I
find bugs in the codebase that was due to the fact that Perl tries "too
damn hard" to be smart.

Sure, some smartness may be fine - but I tend to think these days that
one should be very careful when trying to guess what the developer wanted.

regards, Göran

Louis LaBrunda

[Squeak 4.1] Collections: Failure of Concatenation Operator

On Tue, 26 Oct 2010 19:31:52 +0200, Göran Krampe <[hidden email]> wrote:

>Having spent last months working in a large Perl system I feel much
>stronger about explicitness being a GOOD thing. More than once did I
>find bugs in the codebase that was due to the fact that Perl tries "too
>damn hard" to be smart.

>Sure, some smartness may be fine - but I tend to think these days that
>one should be very careful when trying to guess what the developer wanted.

+1 and a little history. Some 30 to 40 years ago IBM invented PL/1 (for
programming language one) PL/1 was very, very forgiving. We use to joke
that you could feed a Fortran program into PL/1 and it would compile. It
would come up with a bunch of error or warning messages and keep going
trying to guess what the programmer wanted until it had a program it could
run. The resultant program wouldn't do what you wanted but it compiled and
ran.

If you paid attention to the messages, you probably knew the result wasn't
what you wanted but if you didn't, you could be in trouble.

Lou
-----------------------------------------------------------
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon
mailto:[hidden email] http://www.Keystone-Software.com