Path: csiph.com!usenet.pasdenom.info!news.etla.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Mike Amling <mamling@chaff.us>
Newsgroups: comp.lang.java.programmer
Subject: Re: Java blunders
Date: Thu, 31 Jul 2014 13:26:19 -0500
Lines: 66
Message-ID: <c3vg1mFlekeU1@mid.individual.net>
References: <jvbts91r2f9onj1e3dbr5lvqp70hmofkum@4ax.com>	<53cef75d$0$291$14726298@news.sunsite.dk>	<7s6vs9p395bretqrtdvh9i6til83vfk52p@4ax.com>	<53d04b5f$0$291$14726298@news.sunsite.dk>	<sip0t9dqg0c77e7u4o7vo2brs8chsdqok7@4ax.com>	<53d19752$0$295$14726298@news.sunsite.dk>	<jve5t99ju3dgui6974n0tfh6u8jk4nnqet@4ax.com> <lquhi5$q8e$1@dont-email.me>	<qui7t9lvsc2fm0n00tip8ovmlf02r6f4s5@4ax.com> <lr121c$rlo$1@dont-email.me>	<7lcat9t8j6tuo1v2tm1od8rhvhcgf5i7g9@4ax.com> <lr3gcr$aib$1@dont-email.me>	<lr3hde$ruk$1@dont-email.me> <lr3qb8$m9d$1@dont-email.me> <lr3td2$fv9$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net AM+YyOeAooz8C9Aqu801bgfIjY/RBiAglgLZ7v5Hq64J9gy1/A
Cancel-Lock: sha1:rZTNSoUJmTTIQaJJkZBXQcNOawg=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
In-Reply-To: <lr3td2$fv9$1@dont-email.me>
Xref: csiph.com comp.lang.java.programmer:29458

On 7/27/14 5:10 PM, Eric Sosman wrote:
> On 7/27/2014 5:18 PM, Martin Gregorie wrote:
>> On Sun, 27 Jul 2014 14:46:05 -0400, Eric Sosman wrote:
>>
>>> On 7/27/2014 2:28 PM, Martin Gregorie wrote:
>>>> On Sun, 27 Jul 2014 10:13:16 -0700, Roedy Green wrote:
>>>>
>>>>> On Sat, 26 Jul 2014 20:11:24 +0000 (UTC), Martin Gregorie
>>>>> <martin@address-in-sig.invalid> wrote, quoted or indirectly quoted
>>>>> someone who said :
>>>>>
>>>>>> Perl and PHP use . as the string concatenation operator. It seems as
>>>>>> good as any to me:
>>>>>
>>>>> I wonder if . would conflict with its use in qualification.
>>>>>
>>>> That's possible. [...]
>>>
>>>       Yes: An example was offered upthread.  Expanding on it:
>>>
>>>     class Clown {
>>>         static String clownName = "Bozo";
>>>         static {
>>>             System.out.println(clownName.equals("Bozo"));
>>>         }
>>>     }
>>>
>>> What output appears when the class is initialized: "true" or
>>> "Bozofalse"?
>>
>> "False", somewhat obviously, though I don't see what this example has to
>> do with qualififiers, especially given that some compilers understand
>> context-sensitive grammar. In any case, I didn't think this was intended
>> as example code as it looks more like a thinly disguised insult than
>> anything else.
>
>      It wasn't intended as an insult, disguised or in plain view.  It
> was intended to illustrate an ambiguity in the proposed syntax.
>
>      If the `.' were to replace `+' as the string concatenation operator,
> then the expression `clownName.equals("Bozo")' would be ambiguous:  It
> could mean what we now denote as `clownName.equals("Bozo"), that is,
> as "Invoke the equals() method of the `clownName' string, passing
> "Bozo" as the argument."  The output would be "true".
>
>      But if `.' could also be string concatenation, then the expression
> might equally well mean what we now write as `clownName+equals("Bozo")',
> that is, "Invoke the equals method of `this' passing "Bozo" as the

In this particular case, a compile-time error because 'equals' is an 
instance method and 'this' is not defined in a static initializer.

> argument, convert its true or false result to a String, and concatenate
> that String to `clownName'."  The output would be "Bozofalse".
>
>      All non-void String methods accepting a single suitable argument
> would suffer the same ambiguity.  A JavaPrime (Sumatra?) language could
> of course adopt rules to resolve the ambiguity -- but would such a
> suite of rules actually *reduce* the confusion supposedly caused by
> the use of `+'?  C'mon, seriously?
>
>      Cure worse than disease, I think.
Yep.

--Mike Amling
Viva la vie.