On 20.09.2010 19:24, Chris Muller wrote:
> 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.

objection, your honor :)
string concatenation fails if used with something else than
strings. so your enhancements may cause to hide or change bugs.

>
> But to address your argument about consistency, String is already
> unique and pervasive, with other of its own idiosyncracies that are
> "inconsistent" with other kinds of objects.  For example, consider
> String>>#= vs. Object>>#=.  Even String>>#= vs. ByteArray>#=.  Very,
> very different, and "not obvious" what String>#= should do without
> looking at the implementation.

sounds obvious to me. = means test for equality.

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

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 }

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.
thats what my concern is all about.
thanks,
wolfgang


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