As a developer, I, too, always use the standard brace-notation for
creating Arrays and will continue to do so.  This has never been about
introducing an enhanced-API to developers.  My advocacy relates to
exposing an API like this to a _non-developer_ user:

  myDatabase
    select: column1, column2, column3
    where: [ : each | ... ]

so that this string, as entered by the user, without concern for
brace-notation, can be simply evaluated by Smalltalk.

Thanks,
  Chris



On Wed, Sep 22, 2010 at 12:23 PM, Bert Freudenberg <bert at freudenbergs.de> wrote:
> 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
>>
>
>
>
>