terse Object concatenation

> OK, OK, we might implement Character>>#, with a proper rule...
>
> But then, where to stop ?
> Following example was already used:
>   #( 'one'  'two' ) , 'three'.
>   'three' , #( 'two' 'one' ).
> Probably none of the above will be of any use to, nor expected by any end user.
> So the end user argument does not hold to my sense, except if , is
> used in a restricted area, but then why implement it in Object ?
>
> I also can understand the result of a message send is different
> according to the receiver.
> However using athe #difference: operator is a tricky argument :
> concatenation is more akin to sum / union isn't it?.
> Although not symetrical, I could decently expect it to be transitive. Like:
>   self assert: (('abc' , $d ) , $e) = ('abc' , ($d , $e))
>
> Plus some packages will insist on overriding #, to create a matrix, a
> Float array, or something...
>
> Plus the efficiency problem already stated (multiple copies).
>
> All in all, I find the (a,b,c) notation very bright, seducing and
> elegant, but also very deceiptive... It does not hold its promises.
>
>
> Nicolas
>
>> 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
>>
>>
>
>

> > In Smalltalk context maybe it's different, I understand 'abc' , 33 very well.
> >
> > The problem is about common sense expectations / least surprising results.
> > For example, currently
> >   'abc' , $d -> 'abcd'
> > What would you decently expect from:
> >   $a , 'bcd' -> ?
> > Chris, ask your end users if they really understand why concatenating
> > a Character with a String should really answer an Array...
>
> $a , 'bcd' is no different than what they should decently expect from:
>
>   { $a }, 'bcd'
>
> Any guesses?  It's the same answer.  It's consistent, and not just in
> the answer but in the way it is equally "non-obvious".  But I know you
> aren't going to protest concatenation of an Array of Characters with a
> String on those grounds.
>
> These sorts of questions are irrelevant for the real-world scenario
> anyway.  You all are critiquing on the wrong criteria.  You are
> looking for some obscure way to mix a String, what we all know to be a
> special kind of Collection with special behaviors, with another kind
> of objects in order to "look for something non-obvious".  C'mon now...
>
> The fact is that heterogeneous collections are a rarity in real-world
> applications, but this is even a subset of those cases!  e.g., this is
> some hypothetical heterogeneous collection of Strings, Objects,
> Characters that was "accidently" created by some junior programmer,
> because he used concatenation and it gave results he didn't expect
> (but should have), and he didn't test it and so planes fell out of the
> sky.  Ohhh, the humanity of it!"  :-)
>
> I guess I'm feeling frustrated by having to fight so hard against all
> of these fake "problems" for a enhancement has absolutely _no bearing_
> on any of your lives, but tangibly important for my application and
> users.  It's just a simple way for them to express a list of objects
> in a natural way that can be directly interpreted.  Nothing more.
>
> I think you all should let me have this.  If you don't use it, it
> can't affect you.  We haven't run across a regression in the five
> years we've had this in our images, but if we do, I'll certainly fix
> it....
>
>
>
> > OK, OK, we might implement Character>>#, with a proper rule...
> >
> > But then, where to stop ?
> > Following example was already used:
> >   #( 'one'  'two' ) , 'three'.
> >   'three' , #( 'two' 'one' ).
> > Probably none of the above will be of any use to, nor expected by any end user.
> > So the end user argument does not hold to my sense, except if , is
> > used in a restricted area, but then why implement it in Object ?
> >
> > I also can understand the result of a message send is different
> > according to the receiver.
> > However using athe #difference: operator is a tricky argument :
> > concatenation is more akin to sum / union isn't it?.
> > Although not symetrical, I could decently expect it to be transitive. Like:
> >   self assert: (('abc' , $d ) , $e) = ('abc' , ($d , $e))
> >
> > Plus some packages will insist on overriding #, to create a matrix, a
> > Float array, or something...
> >
> > Plus the efficiency problem already stated (multiple copies).
> >
> > All in all, I find the (a,b,c) notation very bright, seducing and
> > elegant, but also very deceiptive... It does not hold its promises.
> >
> >
> > Nicolas
> >
> >> 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
> >>
> >>
> >
> >
>

> Let me illustrate my previous post with what I did in MuO.
>
> MuO is a framework for music composition. Any MusicalElement represent some
> sort of musical data in a temporal framework.
>
> Two MusicalElement instances can always be mixed; the resulting mix is
> always a MusicalElement.
>
> Here enters the concatenation/collection making ambiguity.
>
> If a is a MusicalNote, and b another MusicalNote, then
>
>        a,b
>
> is a MusicalPhrase.
>
> While if a and b are musicalPhrase, then
>
>        a,b
>
> is also a MusicalPhrase.
>
> This is in the line of Chris' proposal (which I am opposed to); the reason I
> find it meaningful here is that both MusicalNote and MusicalPhrase are
> subclasses of MusicalElement.
>
> In the context of what a MusicalElement is, it makes sense that
> concatenation of two objects leads to an object of a different class,
> similar to a collection, because both the initial objects and the collection
> are assured to mix freely via the MusicalElement protocol.
>
> In the general case though, there is no reason that the protocol (taken in
> the broadest sense, as "expected usage") applying to object also applies to
> a collection of objects. Indeed, a collection of object is generally
> ignorant of the nature of its elements. String is an exception and, guess
> what, String does generalize concatenation to non-String objects.
>
> Similarly, AbstractSound implements #, in a way close to Chris' proposal,
> since if a and b are sounds then a,b is a SequentialSound (the analog of
> collection in that case). But note that SequentialSound in an AbstractSound.
>
> So I think we have a pattern here: Chris' proposal make sense to me when it
> operates in a delimited domain where it is clear why we can consider
> anObject to also represent {anObject}. Such a domain implicitely states that
> its objects all have a structural property of potential multiplicity that
> makes it logical that the simplest of these objects can be considered as
> composed of themselves alone.
>
> So a Character is a sort of singleton String, seen from the point of view of
> String. Similarly, an AbstractSound is a singleton SequentialSound, while a
> MusicalNote is a singleton MusicalPhrase, as seen by MusicalElement.
>
> In this way of looking to the problem, Chris's proposal makes the point of
> view of Array important enough that any Object can be seen as an Array
> singleton.
>
> That's where I disagree, for at least two reasons:
> - philosophically, I don't think Array is so central in Smalltalk that we
> have to look to every object through its eyes
> - practically, we have a rich set of Collections, so why pick up Array other
> IdentitySet or SequenceableCollection ?
>
>
> sorry for the long post, hope it was clear...
>
> Stef
>
>
>
>
>
>