Groups > comp.lang.java.programmer > #29201 > unrolled thread

Java blunders

Started by	Roedy Green <see_website@mindprod.com.invalid>
First post	2014-07-22 11:41 -0700
Last post	2014-07-30 10:22 -0500
Articles	20 on this page of 145 — 24 participants

Back to article view | Back to comp.lang.java.programmer

  Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-22 11:41 -0700
    Re: Java blunders Daniele Futtorovic <da.futt.news@laposte.net> - 2014-07-22 21:12 +0200
      Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-22 19:46 -0400
        Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 04:14 -0700
    Re: Java blunders Joerg Meier <joergmmeier@arcor.de> - 2014-07-22 23:47 +0200
      Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 04:23 -0700
        Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-23 12:32 +0000
          Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-23 08:55 -0400
            Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 06:21 -0700
          Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-23 19:53 -0400
            Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 18:49 -0700
        Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-23 19:52 -0400
    Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-22 19:44 -0400
      Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 04:27 -0700
        Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-23 19:55 -0400
          Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 18:53 -0700
            Re: Java blunders Joerg Meier <joergmmeier@arcor.de> - 2014-07-24 11:24 +0200
              Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-25 06:34 -0700
            Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-24 19:31 -0400
              Re: Java blunders Gene Wirchenko <genew@telus.net> - 2014-07-25 13:22 -0700
                Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-25 17:17 -0400
                  Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-25 23:12 +0000
                  Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-26 09:06 -0700
                    Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-26 20:11 +0000
                      Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-26 17:27 -0400
                        Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-27 10:49 -0700
                      Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-27 10:10 -0700
                        Re: Java blunders Gene Wirchenko <genew@telus.net> - 2014-07-28 13:53 -0700
                          Re: Java blunders Stuart <DerTopper@web.de> - 2014-07-30 08:05 +0200
                            Re: Java blunders Sebastian <news@seyweiler.dyndns.org> - 2014-07-30 11:12 +0200
                      Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-27 10:13 -0700
                        Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-27 18:28 +0000
                          Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-27 14:46 -0400
                            Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-27 21:18 +0000
                              Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-27 18:10 -0400
                                Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-28 01:25 +0000
                                  Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-28 08:02 -0400
                                Re: Java blunders Mike Amling <mamling@chaff.us> - 2014-07-31 13:26 -0500
                                  Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-31 14:48 -0400
                          Re: Java blunders "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-07-28 13:22 +0100
                            Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-28 12:52 +0000
                            Re: Java blunders Joerg Meier <joergmmeier@arcor.de> - 2014-07-28 23:38 +0200
                              Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-28 23:17 +0000
                                Re: Java blunders Silvio <silvio@internet.com> - 2014-07-29 13:34 +0200
                                  Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-29 12:45 +0000
                                    Re: Java blunders Silvio <silvio@internet.com> - 2014-07-29 17:10 +0200
                                      Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-29 16:29 +0000
                                        Re: Java blunders lipska the kat <lipskathekat@example.com> - 2014-07-29 20:15 +0100
                                          Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-29 22:02 +0000
                                        Re: Java blunders Silvio <silvio@internet.com> - 2014-07-29 22:43 +0200
                                          Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-29 22:10 +0000
                        Re: Java blunders Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-07-27 19:18 -0500
                        Re: Java blunders Gene Wirchenko <genew@telus.net> - 2014-07-28 13:54 -0700
                      Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-31 23:07 -0400
                        Re: Java blunders James Hostick <james.hostick@gmail.com> - 2014-08-01 22:10 -0700
              Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-26 08:31 -0700
                Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-26 21:04 +0000
                  Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-27 10:51 -0700
                  Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-28 08:50 -0700
                    Re: Java blunders Joerg Meier <joergmmeier@arcor.de> - 2014-07-28 23:42 +0200
                Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-31 23:04 -0400
            Re: Java blunders Josip Almasi <joe@vrspace.org> - 2014-07-28 22:23 +0200
              Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-28 16:39 -0400
                Re: Java blunders Josip Almasi <joe@vrspace.org> - 2014-07-29 00:11 +0200
                Re: Java blunders Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2014-07-30 12:07 +0300
                  Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-30 08:05 -0400
      Re: Java blunders Wanja Gayk <brixomatic@yahoo.com> - 2014-07-25 01:34 +0200
        Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-24 19:43 -0400
    Re: Java blunders Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-07-22 21:02 -0500
      Re: Java blunders Leif Roar Moldskred <leifm@huldreskog.lan> - 2014-07-23 02:01 -0500
        Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 18:58 -0700
        Re: Java blunders thinbluernime <thinbluernime3@gmail.com> - 2014-07-25 03:55 +0000
          Re: Java blunders Leif Roar Moldskred <leifm@huldreskog.lan> - 2014-07-25 00:32 -0500
            Re: Java blunders thinbluernime <thinbluernime3@gmail.com> - 2014-07-26 07:28 +0000
              Re: Java blunders "Gavino" <invalid@invalid.invalid> - 2014-07-26 19:43 +0200
          Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-25 06:36 -0700
            Re: Java blunders "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-07-25 15:47 +0100
              Re: Java blunders David Postill <david.postill@gmail.com> - 2014-07-25 18:29 +0200
              Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-26 09:27 -0700
          Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-25 06:37 -0700
      Re: Java blunders Joerg Meier <joergmmeier@arcor.de> - 2014-07-23 13:17 +0200
        Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 06:27 -0700
      Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 04:44 -0700
        Re: Java blunders Silvio <silvio@internet.com> - 2014-07-23 16:23 +0200
          Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-23 12:02 -0400
            Re: Java blunders Silvio <silvio@internet.com> - 2014-07-24 11:37 +0200
              Re: Java blunders Josip Almasi <joe@vrspace.org> - 2014-07-28 22:37 +0200
          Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 09:33 -0700
            Re: Java blunders thinbluernime <thinbluernime3@gmail.com> - 2014-07-25 03:57 +0000
          Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-23 21:38 -0400
            Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 18:59 -0700
              Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-24 07:33 +0000
            Re: Java blunders Silvio <silvio@internet.com> - 2014-07-24 11:47 +0200
              Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-24 19:34 -0400
                Re: Java blunders Silvio <silvio@internet.com> - 2014-07-25 08:48 +0200
                  Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-25 08:07 -0400
                    Re: Java blunders "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-07-25 13:54 +0100
                  Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-31 22:53 -0400
              Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-25 07:04 -0700
          Re: Java blunders Josip Almasi <joe@vrspace.org> - 2014-07-28 22:01 +0200
        Re: Java blunders Josip Almasi <joe@vrspace.org> - 2014-07-28 21:56 +0200
      Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 06:28 -0700
        Re: Java blunders Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-07-23 08:33 -0500
      Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-23 21:34 -0400
        Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 19:06 -0700
        Re: Java blunders Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-07-23 22:11 -0500
          Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-24 07:36 +0000
            Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-24 19:39 -0400
              Re: Java blunders "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-07-25 13:40 +0100
          Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-24 19:38 -0400
            Re: Java blunders Gene Wirchenko <genew@telus.net> - 2014-07-25 13:30 -0700
    Re: Java blunders taqmcg@gmail.com - 2014-07-23 11:26 -0700
      Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-23 15:14 -0400
        Re: Java blunders thinbluernime <thinbluernime3@gmail.com> - 2014-07-25 04:07 +0000
          Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-25 08:35 -0400
            Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-26 09:41 -0700
          Re: Java blunders Wanja Gayk <brixomatic@yahoo.com> - 2014-08-03 16:41 +0200
            Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-08-03 11:31 -0400
      Re: Java blunders Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-07-23 22:41 -0500
        Re: Java blunders taqmcg@gmail.com - 2014-07-24 10:09 -0700
          Re: Java blunders "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-07-25 13:22 +0100
          Re: Java blunders Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-07-25 20:34 -0500
            Re: Java blunders "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-07-28 13:33 +0100
              Re: Java blunders Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-07-28 08:35 -0500
          Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-26 09:44 -0700
            Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-26 23:36 +0000
    Re: Java blunders Gene Wirchenko <genew@telus.net> - 2014-07-23 20:48 -0700
      Re: Java blunders Silvio <silvio@internet.com> - 2014-07-24 11:56 +0200
        Re: Java blunders Silvio <silvio@internet.com> - 2014-07-24 16:07 +0200
          Re: Java blunders Gene Wirchenko <genew@telus.net> - 2014-07-25 13:38 -0700
            Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-26 10:02 -0700
      Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-24 19:29 -0400
        Re: Java blunders Gene Wirchenko <genew@telus.net> - 2014-07-25 13:45 -0700
      Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-26 10:53 -0700
    Re: Java blunders Wanja Gayk <brixomatic@yahoo.com> - 2014-07-25 01:28 +0200
    Re: Java blunders "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-07-25 14:16 +0100
    Re: Java blunders Joerg Meier <joergmmeier@arcor.de> - 2014-07-25 17:39 +0200
    Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-26 16:21 -0700
    Re: Java blunders Josip Almasi <joe@vrspace.org> - 2014-07-28 23:59 +0200
      Re: Java blunders Josip Almasi <joe@vrspace.org> - 2014-07-29 00:41 +0200
        Re: Java blunders Josip Almasi <joe@vrspace.org> - 2014-07-29 01:54 +0200
      Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-31 22:38 -0400
      Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-31 22:39 -0400
    Re: Java blunders w.tom.adams@gmail.com - 2014-07-30 07:57 -0700
      Re: Java blunders Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-07-30 10:22 -0500

Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →

#29326

From	Eric Sosman <esosman@comcast-dot-net.invalid>
Date	2014-07-25 17:17 -0400
Message-ID	<lquhi5$q8e$1@dont-email.me>
In reply to	#29322

On 7/25/2014 4:22 PM, Gene Wirchenko wrote:
> On Thu, 24 Jul 2014 19:31:29 -0400, Arne Vajhøj <arne@vajhoej.dk>
> wrote:
>
>> On 7/23/2014 9:53 PM, Roedy Green wrote:
>>> On Wed, 23 Jul 2014 19:55:09 -0400, Arne Vajhøj <arne@vajhoej.dk>
>>> wrote, quoted or indirectly quoted someone who said :
>>>> But is it a problem in real world programming?
>>>>
>>>> I have never seen a problem due to this.
>>>
>>> The most common error is like this:
>>>
>>> out.println ( "the answer is " +
>>> a + b
>>> + ".");
>>>
>>> you must write that as:
>>>
>>> out.println ( "the answer is " + (a + b) + ".");
>>
>> But that is not a problem due to reuse of operators.
>
>       But it is.  There are effectively two + operators, and the effect
> is a confusing result.

     I count thirteen + operators:

	+ int
	+ long
	+ float
	+ double
	int + int
	long + long
	float + float (strictfp)
	float + float (not strictfp)
	double + double (strictfp)
	double + double (not strictfp)
	String + String
	String + nonString
	nonString + String

I'll admit to some uncertainty about the implications of strictfp, but
not to any confusion.  Adding an int to an int is a different operation
than adding a double to a double; if that difference isn't "confusing,"
why should adding a String to a Thing be?

     Quick survey: Has anybody encountered a programming language that
possesses a + operator and *doesn't* overload it?  (Long ago I used a
language called SNOBOL3 that might have met this criterion, but long*0.9
ago I'd forgotten all the SNOBOL3 I once knew, so I'm no long-er sure.)

-- 
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#29327

From	Martin Gregorie <martin@address-in-sig.invalid>
Date	2014-07-25 23:12 +0000
Message-ID	<lquo8j$r95$1@dont-email.me>
In reply to	#29326

On Fri, 25 Jul 2014 17:17:51 -0400, Eric Sosman wrote:

>      Quick survey: Has anybody encountered a programming language that
> possesses a + operator and *doesn't* overload it?  (Long ago I used a
> language called SNOBOL3 that might have met this criterion, but long*0.9
> ago I'd forgotten all the SNOBOL3 I once knew, so I'm no long-er sure.)
>
COBOL didn't. If you ignore its use in format strings, which I think is 
allowable, + could only be used in a COMPUTE statement where it meant a 
mathematical add operation, though this was regardless of the way in 
which the operands or the result variable were declared. COBOL numeric 
storage types are many and varied, ranging (in Java notation) from int 
and double to numeric strings with or without a fixed decimal point. 
However, ADD was also implemented, so

   ADD A TO B GIVING C.
and
   COMPUTE C = A + B.

both do exactly the same thing.

PHP is another language that doesn't overload its + operator.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#29337

From	Roedy Green <see_website@mindprod.com.invalid>
Date	2014-07-26 09:06 -0700
Message-ID	<qui7t9lvsc2fm0n00tip8ovmlf02r6f4s5@4ax.com>
In reply to	#29326

On Fri, 25 Jul 2014 17:17:51 -0400, Eric Sosman
<esosman@comcast-dot-net.invalid> wrote, quoted or indirectly quoted
someone who said :

>	String + String
>	String + nonString
>	nonString + String

it is the same symbol but the operation of concatenation is in no way
related to addition.

     a + b + c
any mix of arithmetic types give a least astonishing answer.
If one is a string, you have think carefully what it means.
It MASQUERADES as addition.  

If an expression is not immediately obvious what it roughly means, the
syntax needs an overhaul.  You should not build in stumbling blocks
for the unwary. You are inviting maintenance programmers skimming to
miss the meaning.

We have a hazing problem.  Advanced programmers LIKE things difficult.
They successfully hurdled, and they don't want it easy for those who
come after them.

If we did get a distinct concatenation operator, what would it be?
Pretty much all the ascii combinations are taken, e.g ||.  Maybe % |||
-|- :: _ >< (though >< should be reserved for != ).  Maybe a non-ascii
+ glyph, such as 0x2295 or 0x22c5.  The IDE would convert + to it
where appropriate so you would not have to directly key it. (In that
case it could not have higher priority than +.) Unicode has more
characters than you could shake a stick at, but no official
concatenation operator. 
-- 
Roedy Green Canadian Mind Products http://mindprod.com
The art of strongly-typed language design is largely arranging 
that errors are automatically detected as soon as possible
in the compose, compile, run cycle.

[toc] | [prev] | [next] | [standalone]

#29350

From	Martin Gregorie <martin@address-in-sig.invalid>
Date	2014-07-26 20:11 +0000
Message-ID	<lr121c$rlo$1@dont-email.me>
In reply to	#29337

On Sat, 26 Jul 2014 09:06:28 -0700, Roedy Green wrote:

> If we did get a distinct concatenation operator, what would it be?
>
Perl and PHP use . as the string concatenation operator. It seems as good 
as any to me:

$ perl -e 'print "My cat " . "sat on" . " the mat.\n";'
My cat sat on the mat.
$ 

I'll take issue with your comment about applying + to strings as being 
arithmetical in intent. If that was really the case, then the expression  
"123" + "9"  would return "132" rather than "1239".

Just look at what Perl does with + operator (the same with string 
operands as it does with integers):

$ perl -e 'print "123" + "3" . "\n";'; perl -e 'print 123 + 3 . "\n";'
126
126
$ 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#29354

From	Eric Sosman <esosman@comcast-dot-net.invalid>
Date	2014-07-26 17:27 -0400
Message-ID	<lr16h5$6s0$1@dont-email.me>
In reply to	#29350

On 7/26/2014 4:11 PM, Martin Gregorie wrote:
> On Sat, 26 Jul 2014 09:06:28 -0700, Roedy Green wrote:
>
>> If we did get a distinct concatenation operator, what would it be?
>>
> Perl and PHP use . as the string concatenation operator. It seems as good
> as any to me:
>
> $ perl -e 'print "My cat " . "sat on" . " the mat.\n";'
> My cat sat on the mat.
> $

     I like it!  Let's see:

	if (clownName.equals("Bozo")) ...

     (Oops!)

     As Clemenceau didn't quite say: "What?  Must every little
operation have its own glyph?"

-- 
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#29365

From	Roedy Green <see_website@mindprod.com.invalid>
Date	2014-07-27 10:49 -0700
Message-ID	<nseat9h4bt92n2rnge61kaeefqontmvi8p@4ax.com>
In reply to	#29354

On Sat, 26 Jul 2014 17:27:59 -0400, Eric Sosman
<esosman@comcast-dot-net.invalid> wrote, quoted or indirectly quoted
someone who said :

>     As Clemenceau didn't quite say: "What?  Must every little
>operation have its own glyph?"

so that you will not misread the code.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
The art of strongly-typed language design is largely arranging 
that errors are automatically detected as soon as possible
in the compose, compile, run cycle.

[toc] | [prev] | [next] | [standalone]

#29361

From	Roedy Green <see_website@mindprod.com.invalid>
Date	2014-07-27 10:10 -0700
Message-ID	<tfcat91mkpfpi5k0sasq8o45439138v36k@4ax.com>
In reply to	#29350

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 :

>
>I'll take issue with your comment about applying + to strings as being 
>arithmetical in intent. If that was really the case, then the expression  
>"123" + "9"  would return "132" rather than "1239".

That is not what I intended to say.

Some people look on concatenation as addition defined for strings.

I say NO WAY!  Concatenation has no relation to addition. If addition
were defined on strings, it should add numeric strings, not glue them
together.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
The art of strongly-typed language design is largely arranging 
that errors are automatically detected as soon as possible
in the compose, compile, run cycle.

[toc] | [prev] | [next] | [standalone]

#29407

From	Gene Wirchenko <genew@telus.net>
Date	2014-07-28 13:53 -0700
Message-ID	<uvddt99cnv704olj5rg2v0a03phgn1d8li@4ax.com>
In reply to	#29361

On Sun, 27 Jul 2014 10:10:58 -0700, Roedy Green
<see_website@mindprod.com.invalid> wrote:

[snip]

>Some people look on concatenation as addition defined for strings.
>
>I say NO WAY!  Concatenation has no relation to addition. If addition
>were defined on strings, it should add numeric strings, not glue them
>together.

     But it does.  The word "add" is used in English to mean appending
to a string.  e.g. Add "ice cream" to the shopping list.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#29435

From	Stuart <DerTopper@web.de>
Date	2014-07-30 08:05 +0200
Message-ID	<lra203$c8i$1@dont-email.me>
In reply to	#29407

On 07/27/14, Roedy Green wrote:
> [snip]
>
>> Some people look on concatenation as addition defined for strings.
>>
>> I say NO WAY!  Concatenation has no relation to addition. If addition
>> were defined on strings, it should add numeric strings, not glue them
>> together.

On 07/28/14, Gene Wirchenko wrote:
> But it does.  The word "add" is used in English to mean appending
> to a string.  e.g. Add "ice cream" to the shopping list.

I have no problem with using '+' for string concatenation. Apparently 
others feel differently. In our CS lectures on formal languages the 
symbol U+2218 (the ordinary symbol for multiplication, but as a small 
circle) was used.

In the language of my dreams one would be able to define their own 
operators (IMHO it is really sad that you even cannot overload the 
existing operators in Java). In that case I would choose U+2295 (a plus 
sign with a circle around it), but apparently some people would use this 
operator rather for an exclusive-or.

Regards,
Stuart

[toc] | [prev] | [next] | [standalone]

#29438

From	Sebastian <news@seyweiler.dyndns.org>
Date	2014-07-30 11:12 +0200
Message-ID	<lracuh$gvf$1@news.albasani.net>
In reply to	#29435

Am 30.07.2014 08:05, schrieb Stuart:> On 07/27/14, Roedy Green wrote:
 >> [snip]
 >>
 >>> Some people look on concatenation as addition defined for strings.
 >>>
 >
 > On 07/28/14, Gene Wirchenko wrote:
 >> But it does.  The word "add" is used in English to mean appending
 >> to a string.  e.g. Add "ice cream" to the shopping list.
 >
 >
 > I have no problem with using '+' for string concatenation. Apparently
 > others feel differently. In our CS lectures on formal languages the
 > symbol U+2218 (the ordinary symbol for multiplication, but as a small
 > circle) was used.
 >

If you want an analogy between string concatenation and operations on 
integers, it is indeed rather more natural to choose multiplication 
instead of addition as the analogue. Both the set of strings with 
concatenation and the integers with multiplication form a monoid, while 
the integers with addition already form a group. Also, it is customary 
in group theory to prefer "+" for commutative operations, while 
something like the multiplication sign is preferred for non-commutative 
operations.

So while from this perspective it may be considered unfortunate that the 
overloading of the addition operator for string concatenation is so 
widespread in programming languages, I'd not consider this a "blunder": 
conventions may differ.

-- Sebastian

[toc] | [prev] | [next] | [standalone]

#29362

From	Roedy Green <see_website@mindprod.com.invalid>
Date	2014-07-27 10:13 -0700
Message-ID	<7lcat9t8j6tuo1v2tm1od8rhvhcgf5i7g9@4ax.com>
In reply to	#29350

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.

I used a language many years ago, that used space as the concatenation
operator.  Does anyone remember what it was?  SNOBOL?

It made for very readable code.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
The art of strongly-typed language design is largely arranging 
that errors are automatically detected as soon as possible
in the compose, compile, run cycle.

[toc] | [prev] | [next] | [standalone]

#29367

From	Martin Gregorie <martin@address-in-sig.invalid>
Date	2014-07-27 18:28 +0000
Message-ID	<lr3gcr$aib$1@dont-email.me>
In reply to	#29362

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. Perl side-steps it by using -> as its qualifier, quite 
possible because by the time Larry Wall felt to need to extend Perl to 
handle the equivalent of C structs or Java classes the '.' was already 
being used as the string concatenation operator.

With all the problems around thinking up intuitive and preferably very 
short symbols to represent a growing number of operators I'm getting more 
and more inclined to think that the Algol 68 authors were on the right 
track with their approach of allowing a programmer overload any operator 
he wanted to provided there wasn't a pre-existing example on the A68  
equivalent of the class-path.

> I used a language many years ago, that used space as the concatenation
> operator.  Does anyone remember what it was?  SNOBOL?
> 
> It made for very readable code.
>
Same applies to operator overloading: given a CurrentAccount object ca 
and a Payment object p there 's little or no difference in clarity 
between writing

	ca.acceptPayment(p);

and
	ca += p;



-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#29368

From	Eric Sosman <esosman@comcast-dot-net.invalid>
Date	2014-07-27 14:46 -0400
Message-ID	<lr3hde$ruk$1@dont-email.me>
In reply to	#29367

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

-- 
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#29369

From	Martin Gregorie <martin@address-in-sig.invalid>
Date	2014-07-27 21:18 +0000
Message-ID	<lr3qb8$m9d$1@dont-email.me>
In reply to	#29368

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.
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#29370

From	Eric Sosman <esosman@comcast-dot-net.invalid>
Date	2014-07-27 18:10 -0400
Message-ID	<lr3td2$fv9$1@dont-email.me>
In reply to	#29369

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

-- 
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#29377

From	Martin Gregorie <martin@address-in-sig.invalid>
Date	2014-07-28 01:25 +0000
Message-ID	<lr48qv$4ur$2@dont-email.me>
In reply to	#29370

On Sun, 27 Jul 2014 18:10:42 -0400, Eric Sosman wrote:

>      If the `.' were to replace `+' as the string concatenation
>      operator,
> then the expression `clownName.equals("Bozo")' would be ambiguous
>
It would be more likely to generate a compile-time error because neither 
operand was a String and/or could not be coerced into one.

However, I must admit that I hadn't thought of that ambiguity, not least 
because Perl and PHP coders tend to put a space on either side of '.', 
probably to make its presence easier to spot.

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#29388

From	Eric Sosman <esosman@comcast-dot-net.invalid>
Date	2014-07-28 08:02 -0400
Message-ID	<lr5e4a$8gn$1@dont-email.me>
In reply to	#29377

On 7/27/2014 9:25 PM, Martin Gregorie wrote:
> On Sun, 27 Jul 2014 18:10:42 -0400, Eric Sosman wrote:
>
>>       If the `.' were to replace `+' as the string concatenation
>>       operator,
>> then the expression `clownName.equals("Bozo")' would be ambiguous
>>
> It would be more likely to generate a compile-time error because neither
> operand was a String and/or could not be coerced into one.

     The declaration you snipped was

	static String clownName = "Bozo";

Coercion of this reference to String type is something any smart
compiler should be able to handle.  :)

> However, I must admit that I hadn't thought of that ambiguity, not least
> because Perl and PHP coders tend to put a space on either side of '.',
> probably to make its presence easier to spot.

     Remember, the goal of changing the string concatenation operator
from `+' to something else is to reduce confusion.  Would it reduce
confusion to make `.' and ` . ' behave differently?

-- 
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#29458

From	Mike Amling <mamling@chaff.us>
Date	2014-07-31 13:26 -0500
Message-ID	<c3vg1mFlekeU1@mid.individual.net>
In reply to	#29370

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.

[toc] | [prev] | [next] | [standalone]

#29459

From	Eric Sosman <esosman@comcast-dot-net.invalid>
Date	2014-07-31 14:48 -0400
Message-ID	<lre31b$k0m$1@dont-email.me>
In reply to	#29458

On 7/31/2014 2:26 PM, Mike Amling wrote:
> On 7/27/14 5:10 PM, Eric Sosman wrote:
>> [...]
>>      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.

     Good catch!  (Oh, ratz...)

-- 
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#29389

From	"Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org>
Date	2014-07-28 13:22 +0100
Message-ID	<oqudncJQXNfN3EvOnZ2dnUVZ8sqdnZ2d@bt.com>
In reply to	#29367

Martin Gregorie wrote:

>
> Same applies to operator overloading: given a CurrentAccount object ca
> and a Payment object p there 's little or no difference in clarity
> between writing
>
> ca.acceptPayment(p);
>
> and
> ca += p;

The latter pattern is used a lot in C# / .Net framework.  For instance you use 
+= to add listeners for events.  It keeps the code short, but does nothing for 
clarity IMO.

Your example of adding a depost to an account using += may make more sense, but 
even there I think it's more "cute" than "clear".  OTOH, if Java had (say) "->" 
and "<-" as generic (not Generic) operators for "putting stuff into places" and 
"getting stuff from places" (pace the discusion elsethread about notation for 
IO), then I'd be all for:

    ca <- p;

    -- chris

[toc] | [prev] | [next] | [standalone]

Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →

csiph-web

Java blunders

Contents

#29326

#29327

#29337

#29350

#29354

#29365

#29361

#29407

#29435

#29438

#29362

#29367

#29368

#29369

#29370

#29377

#29388

#29458

#29459

#29389