On 22.09.2010, at 18:14, Chris Muller wrote:

>>> First, let me clarify that standard String concatenation is
>>> unaffected, of course.  Nothing about this enhancement has any affect
>>> on any legacy code.
>> 
>> objection, your honor :)
>> string concatenation fails if used with something else than
>> strings. so your enhancements may cause to hide or change bugs.
> 
> No, I don't think so.
> 
>   'hello', Object new ---> "'helloan Object'"
> 
>   Object new, 'hello' ---> "{an Object . $h . $e . $l . $l . $o}"
> 
> Where is the "failure?"
> 
> If you notice the timestamp on the methods, you will see that we have
> been using this for over five years.

Stringification of any object in String>>, was only added last year. Until then, there was no generic protocol involving #, it was only for special classes (Collections, Exceptions, Sounds).

It made (some) sense for Strings because it's just too convenient being able to write ('the value is ', aNumber) without having to convert aNumber to a String first.

For making Arrays I prefer the brace notation. E.g. if you want to return two objects from a method you still would need to write ^{a. b} because if you write ^a,b would break if the first object happens to be a collection. Also, brace notation is more efficient with more than 2 elements because it avoids unnecessarily copying the intermediate collections.

That said, I wouldn't really mind adding your feature. It's just one more reason to advise people to avoid concatenation in production code whenever possible ;)

- Bert -

>  We have not noticed anything
> broken during that time.  So, won't you please back up your claim with
> an example?
> 
>> yes, i understand what your enhancement does.
>> it just that we disagree about whether it is beneficial
>> to be able to use
>> obj, obj
>> instead of
>> { obj. obj }
> 
> It is not "instead of" it is "in addition to".  It's use is optional.
> You are not forced to use it.  However, I don't want to force my
> non-technical users to have to write
> 
>  { column1. column2. column 3. }
> 
> instead of
> 
>  column1, column2, column3
> 
> For non-technical users, the latter _is_ beneficial because it is more
> natural.  I'm not talking about them writing Smalltalk methods, I'm
> talking about when they specify, for example, a list of columns in a
> text-input field in the user-interface that the program to which I
> apply Smalltalk interpretation (it's actually more sophisticated than
> that, but for sake of simple explanation..).
> 
>> i happen to think the opposite (i.e. not beneficial)
>> because it is not universal. i.e. it makes a difference
>> string , object
>> object , object
> 
> I'm not sure what you mean by "not universal".  That is like saying
> you are opposed to overloading in general..??  This is consistent with
> other overloads in that the receiver of the message determines the
> behavior, just like in other methods (like Collection>>#difference:
> which you did not address).  If an Object receives it, you get a
> pointer-list of objects because the receiver is a pointer object.  If
> a String receives it, you get a byte-list of characters because the
> receiver is a byte object.  Isn't that completely consistent and
> logical.
> 
> ----
> 
> So far the arguments presented against this are:
> 
>  - "string concatenation fails if used with something else than strings"
>  - "not beneficial"
>  - "not universal"
>  - "awkward and hackish"
> 
> I hope these are addressed these to your satisfaction.  If not, at
> least you can opt out from using it and, in five years of using it,
> has presented no ill-effects on any legacy code..
> 
> - Chris
>