terse Object concatenation

> I would like to integrate this elegant extension to the
> object-concatenation API.  Just as Exceptions may be easily
> concatenated with the #, (comma) selector, now any object may, as
> well:
>
>  object1, object2  --> "{ object1.  object2 }"
>
> and, equally, with other collections:
>
>  { object1.  object2 }, object3 --> "{ object1.  object2. object3 }"

> I would like to integrate this elegant extension to the
> object-concatenation API.  Just as Exceptions may be easily
> concatenated with the #, (comma) selector, now any object may, as
> well:
>
>    object1, object2  -->  "{ object1.  object2 }"
>
> and, equally, with other collections:
>
>    { object1.  object2 }, object3 -->  "{ object1.  object2. object3 }"
>
> I find this particularly useful for user-interfaces that apply
> Smalltalk interpretation to user text input, that the user was able to
> write "lists" of items in a very terse and natural way rather than
> demanding curly-brace developer-syntax.
>
> I do not wish to reopen philosophical discussions; this is right
> in-line with the spirit of Squeak's other concatenation conveniences.
> There were no major objections when I proposed this a couple of months
> ago, and if that is still true, I would therefore like to go ahead and
> merge these 5 new methods into the trunk later this week.
>
>   - Chris
>
>

> dear chris,
> i believe that this is not possible to do in a consistent manner,
> because:
> string , string means string concatenation
> object , object means collection creation
>
> so it is not obvious (to me at least) what
> string , object
> object , string
> should actually do.
>
> and then there's the fact that strings are
> collections too, so
> string , $c
> $c , string
> have yet another set of possible meanings.
>
> just my 2c
> thanks
> wolfgang
>
> On 19.09.2010 22:53, Chris Muller wrote:
>>
>> I would like to integrate this elegant extension to the
>> object-concatenation API.  Just as Exceptions may be easily
>> concatenated with the #, (comma) selector, now any object may, as
>> well:
>>
>>   object1, object2  -->  "{ object1.  object2 }"
>>
>> and, equally, with other collections:
>>
>>   { object1.  object2 }, object3 -->  "{ object1.  object2. object3 }"
>>
>> I find this particularly useful for user-interfaces that apply
>> Smalltalk interpretation to user text input, that the user was able to
>> write "lists" of items in a very terse and natural way rather than
>> demanding curly-brace developer-syntax.
>>
>> I do not wish to reopen philosophical discussions; this is right
>> in-line with the spirit of Squeak's other concatenation conveniences.
>> There were no major objections when I proposed this a couple of months
>> ago, and if that is still true, I would therefore like to go ahead and
>> merge these 5 new methods into the trunk later this week.
>>
>>  - Chris
>>
>>
>
>
>

> Hello,
>
>> i believe that this is not possible to do in a consistent manner,
>> because:
>> string , string means string concatenation
>> object , object means collection creation
>
> First, let me clarify that standard String concatenation is
> unaffected, of course.  Nothing about this enhancement has any affect
> on any legacy code.

>
>> so it is not obvious (to me at least) what
>> string , object
>> object , string
>> should actually do.
>
> It is based on the receiver of the message.  Like the way you get
> different results from:
>
>     { 1. 2. 3} difference: { 2. 3 }.
>     { 2. 3} difference: { 1. 2. 3 }
>
> depending on which is the receiver...

>
>> and then there's the fact that strings are
>> collections too, so
>> string , $c
>> $c , string
>> have yet another set of possible meanings.
>
> This is the same meaning as above.  The Character is the "object" and
> the receiver determines what happens..
>
> Hope this helps,
>    Chris
>
>

> it just that we disagree about whether it is beneficial
> to be able to use
> obj, obj
> instead of
> { obj. obj }
>
> 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
>
> results in two different behaviours.

>>> 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.

>  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
>

> 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
>>
>
>
>
>

>>>>>> "Chris" == Chris Muller <[hidden email]> writes:
>
>>> I agree, it looks akward and hackish to me too; a step backward from the
>>> nice API for collections we currently have.
>
> Chris> I guess I just don't understand why:
>
> Chris>   field1, field2, field3
>
> Chris> looks "awkward and hackish?"  It is the most natural way to express a
> Chris> "list" of things that you can possibly have...
>
> Funny thing that.  We already have:
>
>      { field1 . field2 . field3 }
>
> which to me reads even clearer.
>
> Chris> You don't have use it.  It's optional.
>
> Until it hides a problem.  Or breaks something else.
>
> I vote no if I get a vote.
>
> --
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
> <[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
> See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
>

> 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.

> On 9/22/2010 10:23 AM, Bert Freudenberg wrote:
>> 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.
>
> Same here. I'm not a strong proponent of object-object concatenation (though I *am* a strong proponent of string-object concatenation :-) but I don't mind it either. I can sort of see the appeal of writing "1, 2" but it's just something that I don't do often outside of literal string concatenation.
>
> From my view brace syntax is slightly advantageous for complex constructs since it avoids additional parenthesis and can be indented properly as in:
>
> self doWithArgs: {
> self methodFoo: 42.
> 17 sqrt.
> 'Hello', 'World'.
> }
>
> vs.
>
> self doWithArgs: (self methodFoo: 42), 17 sqrt, ('Hello', 'World')

> On 9/22/2010 10:23 AM, Bert Freudenberg wrote:
>>
>> 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.
>
> Same here. I'm not a strong proponent of object-object concatenation (though
> I *am* a strong proponent of string-object concatenation :-) but I don't
> mind it either. I can sort of see the appeal of writing "1, 2" but it's just
> something that I don't do often outside of literal string concatenation.
>

> From my view brace syntax is slightly advantageous for complex constructs
> since it avoids additional parenthesis and can be indented properly as in:
>
>        self doWithArgs: {
>                self methodFoo: 42.
>                17 sqrt.
>                'Hello', 'World'.
>        }
>
> vs.
>
>        self doWithArgs: (self methodFoo: 42), 17 sqrt, ('Hello', 'World')
>
> But then again I really don't feel strongly about it.
>
> Cheers,
>  - Andreas
>
>