[squeak-dev] Re: terse Object concatenation

Chris Muller asqueaker at gmail.com
Thu Sep 23 19:07:35 UTC 2010


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



More information about the Squeak-dev mailing list