Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

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

Java blunders

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

Contents

  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 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8  Next page →

#29391

On Mon, 28 Jul 2014 13:22:49 +0100, Chris Uppal wrote:

> 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;
>
Yes, Mine wasn't a particularly good example. I should have used a real-
life one. Given: 

- a PICTURE mode (which holds a 2D plottable diagram, 
  scaled and ready to output 

- a SKETCH mode, which holds details of an unscaled item that can
  be plotted after its scaled and positioned in a PICTURE

- a set of modes (RECTANGLE, CIRCLE, TEXT) derived from SKETCH

and given the objects:

RECTANGLE  r;
CIRCLE c;
TEXT t;

you could write

PICTURE p = r + c + t;

which I would say is entirely understandable and unambiguous. Using this 
library I wrote an Algol 68R program that drew a rectangular frame, 
filled it with a number of randomly sized and placed circles, wrote 
'BUBBLES' centred in the frame, and output the completed image on a line 
printer. It was my test piece to make sure I'd installed the graphics 
library correctly. It was a 10 line program and pretty much readable by 
any programmer.

I used the financial example because I thought it would need less 
explanation: obviously a mistake.


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

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

#29411

On Mon, 28 Jul 2014 13:22:49 +0100, Chris Uppal wrote:

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

While I often wished we had that kind of operator overloading, my biggest
issue with it is that it looks like it is reassigning ca (and the explicit
syntax, "ca = ca + p;", is even worse), when it in fact doesn't. And that
opens all kind of worm cans: 

- Can ca still be declared final ? If yes, you suddenly have final
variables looking like they are assigned again. If no, you lose that
modifier for no technical reason.

- Scope visibility suffers - private bla(Foo foo) { foo += new Bar(); } --
does this affect the state of foo ? I can't tell, and neither can you
without looking at Foo.java

- Is "ca + p" an expression ? Or a statement ? If you take away the "ca ="
part, does "ca + p" still do anything ? Could you have "ca+p;", and what
exactly would that do ?

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

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

#29420

On Mon, 28 Jul 2014 23:38:03 +0200, Joerg Meier wrote:

> While I often wished we had that kind of operator overloading, my
> biggest issue with it is that it looks like it is reassigning ca (and
> the explicit syntax, "ca = ca + p;", is even worse), when it in fact
> doesn't. And that opens all kind of worm cans:
>
You're reading too much into it. IIRC Algol 68 had the += operator and 
you might choose to overload either + or += to represent paying a cheque 
into an account. It seemed to me that in this case overloading += would 
read better than overloading + might. 
 
> - Can ca still be declared final ?
>
No - at least you couldn't in Algol 68. It wasn't really an OO language. 
Although it had a lot of features that became integral parts of the OO 
paradigm, it didn't any concept of a class or objects that might contain 
both data and methods. A mode was quite similar to a C struct, and code 
only existed as procedures and operators.
 
If you take away the "ca =" part, does "ca + p" still do anything? Yes, 
in exactly the same way that you can throw away the value returned by a 
Java method or a C function.  

Could you have "ca+p;", 

Yes. It would do whatever you'd written the new operator overloading + to 
do. If it was defined as 
op +(account,cheque):             it would return nothing, while 
op +(account,cheque)int:          might return the new balance and
op +=(account,cheque)ref account: would return a reference to the account.

As I said: this was Algol 68, which is not an OO language though I 
suspect that its operator overloading is very much in the spirit of the 
idea that messages are passed between objects and the A68 compiler had to 
do more or less the same when parsing an overloaded operator as the Java 
compiler does when parsing an overloaded method. 


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

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

#29424

On 07/29/2014 01:17 AM, Martin Gregorie wrote:
> On Mon, 28 Jul 2014 23:38:03 +0200, Joerg Meier wrote:
>
>> While I often wished we had that kind of operator overloading, my
>> biggest issue with it is that it looks like it is reassigning ca (and
>> the explicit syntax, "ca = ca + p;", is even worse), when it in fact
>> doesn't. And that opens all kind of worm cans:
>>
> You're reading too much into it. IIRC Algol 68 had the += operator and
> you might choose to overload either + or += to represent paying a cheque
> into an account. It seemed to me that in this case overloading += would
> read better than overloading + might.
>
>> - Can ca still be declared final ?
>>
> No - at least you couldn't in Algol 68. It wasn't really an OO language.
> Although it had a lot of features that became integral parts of the OO
> paradigm, it didn't any concept of a class or objects that might contain
> both data and methods. A mode was quite similar to a C struct, and code
> only existed as procedures and operators.
>
> If you take away the "ca =" part, does "ca + p" still do anything? Yes,
> in exactly the same way that you can throw away the value returned by a
> Java method or a C function.
>
> Could you have "ca+p;",
>
> Yes. It would do whatever you'd written the new operator overloading + to
> do. If it was defined as
> op +(account,cheque):             it would return nothing, while
> op +(account,cheque)int:          might return the new balance and
> op +=(account,cheque)ref account: would return a reference to the account.
>
> As I said: this was Algol 68, which is not an OO language though I
> suspect that its operator overloading is very much in the spirit of the
> idea that messages are passed between objects and the A68 compiler had to
> do more or less the same when parsing an overloaded operator as the Java
> compiler does when parsing an overloaded method.
>
>

Oh, the good old days. I used to love the tagged unions.

Algol 68 was the language with which I was taught how to program in 
1985. Not the easiest introduction imaginable but professor CHA Koster 
made such a compelling effort that I saw it through.

He was on the original committee that defined the language in 1968. It's 
a shame he passed away last year.

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

#29426

On Tue, 29 Jul 2014 13:34:46 +0200, Silvio wrote:

> On 07/29/2014 01:17 AM, Martin Gregorie wrote:
>> On Mon, 28 Jul 2014 23:38:03 +0200, Joerg Meier wrote:
>>
>>> While I often wished we had that kind of operator overloading, my
>>> biggest issue with it is that it looks like it is reassigning ca (and
>>> the explicit syntax, "ca = ca + p;", is even worse), when it in fact
>>> doesn't. And that opens all kind of worm cans:
>>>
>> You're reading too much into it. IIRC Algol 68 had the += operator and
>> you might choose to overload either + or += to represent paying a
>> cheque into an account. It seemed to me that in this case overloading
>> += would read better than overloading + might.
>>
>>> - Can ca still be declared final ?
>>>
>> No - at least you couldn't in Algol 68. It wasn't really an OO
>> language. Although it had a lot of features that became integral parts
>> of the OO paradigm, it didn't any concept of a class or objects that
>> might contain both data and methods. A mode was quite similar to a C
>> struct, and code only existed as procedures and operators.
>>
>> If you take away the "ca =" part, does "ca + p" still do anything? Yes,
>> in exactly the same way that you can throw away the value returned by a
>> Java method or a C function.
>>
>> Could you have "ca+p;",
>>
>> Yes. It would do whatever you'd written the new operator overloading +
>> to do. If it was defined as op +(account,cheque):             it would
>> return nothing, while op +(account,cheque)int:          might return
>> the new balance and op +=(account,cheque)ref account: would return a
>> reference to the account.
>>
>> As I said: this was Algol 68, which is not an OO language though I
>> suspect that its operator overloading is very much in the spirit of the
>> idea that messages are passed between objects and the A68 compiler had
>> to do more or less the same when parsing an overloaded operator as the
>> Java compiler does when parsing an overloaded method.
>>
>>
>>
> Oh, the good old days. I used to love the tagged unions.
> 
> Algol 68 was the language with which I was taught how to program in
> 1985. Not the easiest introduction imaginable but professor CHA Koster
> made such a compelling effort that I saw it through.
> 
> He was on the original committee that defined the language in 1968. It's
> a shame he passed away last year.
>
Sad news.

Algol 68R, which was an implementation for ICL 1900 mainframes running 
George 3, was written at the Radar Research Establishment in Malvern, UK. 
It was one of the nicest compilation systems I've used anywhere. Compiler 
error reporting was clear and to the point and the compiler was fast. Run-
time performance was good too and the crash diagnostics were among the 
best I've ever seen: as well as showing more or less the same as a Java 
crash does, it also dumped all variables that were in scope when the 
crash happened (in appropriate formats) and then showed a trace-back of 
how you'd got to that point. As well as the procedure call stack it 
showed for and while loops (and how many iterations they'd run), 
conditionals (and which branch was taken) and gave source line numbers 
for everything as well.


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

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

#29427

On 07/29/2014 02:45 PM, Martin Gregorie wrote:

> Sad news.
>
> Algol 68R, which was an implementation for ICL 1900 mainframes running
> George 3, was written at the Radar Research Establishment in Malvern, UK.
> It was one of the nicest compilation systems I've used anywhere. Compiler
> error reporting was clear and to the point and the compiler was fast. Run-
> time performance was good too and the crash diagnostics were among the
> best I've ever seen: as well as showing more or less the same as a Java
> crash does, it also dumped all variables that were in scope when the
> crash happened (in appropriate formats) and then showed a trace-back of
> how you'd got to that point. As well as the procedure call stack it
> showed for and while loops (and how many iterations they'd run),
> conditionals (and which branch was taken) and gave source line numbers
> for everything as well.
>
>

Sweet.

We worked on a mainframe clone of the IBM/370 running VM/370 (CP/CMS). 
We used the FLACC compiler which was supposed to conform to the Revised 
Report. It did have some debugging support but since we where students 
and allowed only limited access to the mainframe we had to do without 
such advanced features. Compile => fix compiler errors => repeat and 
then compile => run => fix errors => repeat is about what we did.

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

#29429

On Tue, 29 Jul 2014 17:10:46 +0200, Silvio wrote:

> On 07/29/2014 02:45 PM, Martin Gregorie wrote:
> 
>> Sad news.
>>
>> Algol 68R, which was an implementation for ICL 1900 mainframes running
>> George 3, was written at the Radar Research Establishment in Malvern,
>> UK. It was one of the nicest compilation systems I've used anywhere.
>> Compiler error reporting was clear and to the point and the compiler
>> was fast. Run-
>> time performance was good too and the crash diagnostics were among the
>> best I've ever seen: as well as showing more or less the same as a Java
>> crash does, it also dumped all variables that were in scope when the
>> crash happened (in appropriate formats) and then showed a trace-back of
>> how you'd got to that point. As well as the procedure call stack it
>> showed for and while loops (and how many iterations they'd run),
>> conditionals (and which branch was taken) and gave source line numbers
>> for everything as well.
>>
>>
>>
> Sweet.
> 
> We worked on a mainframe clone of the IBM/370 running VM/370 (CP/CMS).
> We used the FLACC compiler which was supposed to conform to the Revised
> Report. It did have some debugging support but since we where students
> and allowed only limited access to the mainframe we had to do without
> such advanced features. Compile => fix compiler errors => repeat and
> then compile => run => fix errors => repeat is about what we did.

Been there, done it. Write ICL assembler (PLAN3) or COBOL on coding 
sheets, punch the cards yourself with a 12 key manual punch if time was 
short and then get one overnight compile&test run a day plus a lunchtime 
run if we were lucky and could operate the machine ourselves (this was 
pre-George 3). Use the punch again to fix errors and shuffle them into 
the pack. Still, even at that stage we were a little better off than IBM 
guys because we kept source on tape or disk long before most of them did 
and had card-driven line editors to fix the source in situ.

But, tell this to the kids today ........


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

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

#29430

On 29/07/14 17:29, Martin Gregorie wrote:
> On Tue, 29 Jul 2014 17:10:46 +0200, Silvio wrote:
>
>> On 07/29/2014 02:45 PM, Martin Gregorie wrote:
>>
>>> Sad news.
>>>
>>> Algol 68R, which was an implementation for ICL 1900 mainframes running
>>> George 3, was written at the Radar Research Establishment in Malvern,
>>> UK. It was one of the nicest compilation systems I've used anywhere.
>>> Compiler error reporting was clear and to the point and the compiler
>>> was fast. Run-
>>> time performance was good too and the crash diagnostics were among the
>>> best I've ever seen: as well as showing more or less the same as a Java
>>> crash does, it also dumped all variables that were in scope when the
>>> crash happened (in appropriate formats) and then showed a trace-back of
>>> how you'd got to that point. As well as the procedure call stack it
>>> showed for and while loops (and how many iterations they'd run),
>>> conditionals (and which branch was taken) and gave source line numbers
>>> for everything as well.
>>>
>>>
>>>
>> Sweet.
>>
>> We worked on a mainframe clone of the IBM/370 running VM/370 (CP/CMS).
>> We used the FLACC compiler which was supposed to conform to the Revised
>> Report. It did have some debugging support but since we where students
>> and allowed only limited access to the mainframe we had to do without
>> such advanced features. Compile => fix compiler errors => repeat and
>> then compile => run => fix errors => repeat is about what we did.
>
> Been there, done it. Write ICL assembler (PLAN3) or COBOL on coding
> sheets, punch the cards yourself with a 12 key manual punch if time was
> short and then get one overnight compile&test run a day plus a lunchtime
> run if we were lucky and could operate the machine ourselves (this was
> pre-George 3). Use the punch again to fix errors and shuffle them into
> the pack. Still, even at that stage we were a little better off than IBM
> guys because we kept source on tape or disk long before most of them did
> and had card-driven line editors to fix the source in situ.
>
> But, tell this to the kids today ........
>
>

http://www.davidpbrown.co.uk/jokes/monty-python-four-yorkshiremen.html

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer,
treacherous feline and farscape dreamer of Aeryn Sun
GNU/Linux user #560883 - http://www.linuxcounter.net

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

#29432

On Tue, 29 Jul 2014 20:15:19 +0100, lipska the kat wrote:

> On 29/07/14 17:29, Martin Gregorie wrote:
>> On Tue, 29 Jul 2014 17:10:46 +0200, Silvio wrote:
>>
>>> On 07/29/2014 02:45 PM, Martin Gregorie wrote:
>>>
>>>> Sad news.
>>>>
>>>> Algol 68R, which was an implementation for ICL 1900 mainframes
>>>> running George 3, was written at the Radar Research Establishment in
>>>> Malvern, UK. It was one of the nicest compilation systems I've used
>>>> anywhere. Compiler error reporting was clear and to the point and the
>>>> compiler was fast. Run-
>>>> time performance was good too and the crash diagnostics were among
>>>> the best I've ever seen: as well as showing more or less the same as
>>>> a Java crash does, it also dumped all variables that were in scope
>>>> when the crash happened (in appropriate formats) and then showed a
>>>> trace-back of how you'd got to that point. As well as the procedure
>>>> call stack it showed for and while loops (and how many iterations
>>>> they'd run), conditionals (and which branch was taken) and gave
>>>> source line numbers for everything as well.
>>>>
>>>>
>>>>
>>> Sweet.
>>>
>>> We worked on a mainframe clone of the IBM/370 running VM/370 (CP/CMS).
>>> We used the FLACC compiler which was supposed to conform to the
>>> Revised Report. It did have some debugging support but since we where
>>> students and allowed only limited access to the mainframe we had to do
>>> without such advanced features. Compile => fix compiler errors =>
>>> repeat and then compile => run => fix errors => repeat is about what
>>> we did.
>>
>> Been there, done it. Write ICL assembler (PLAN3) or COBOL on coding
>> sheets, punch the cards yourself with a 12 key manual punch if time was
>> short and then get one overnight compile&test run a day plus a
>> lunchtime run if we were lucky and could operate the machine ourselves
>> (this was pre-George 3). Use the punch again to fix errors and shuffle
>> them into the pack. Still, even at that stage we were a little better
>> off than IBM guys because we kept source on tape or disk long before
>> most of them did and had card-driven line editors to fix the source in
>> situ.
>>
>> But, tell this to the kids today ........
>>
>>
>>
> http://www.davidpbrown.co.uk/jokes/monty-python-four-yorkshiremen.html

Of course! Well spotted.


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

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

#29431

On 07/29/2014 06:29 PM, Martin Gregorie wrote:
> On Tue, 29 Jul 2014 17:10:46 +0200, Silvio wrote:
>
>> On 07/29/2014 02:45 PM, Martin Gregorie wrote:
>>
>>> Sad news.
>>>
>>> Algol 68R, which was an implementation for ICL 1900 mainframes running
>>> George 3, was written at the Radar Research Establishment in Malvern,
>>> UK. It was one of the nicest compilation systems I've used anywhere.
>>> Compiler error reporting was clear and to the point and the compiler
>>> was fast. Run-
>>> time performance was good too and the crash diagnostics were among the
>>> best I've ever seen: as well as showing more or less the same as a Java
>>> crash does, it also dumped all variables that were in scope when the
>>> crash happened (in appropriate formats) and then showed a trace-back of
>>> how you'd got to that point. As well as the procedure call stack it
>>> showed for and while loops (and how many iterations they'd run),
>>> conditionals (and which branch was taken) and gave source line numbers
>>> for everything as well.
>>>
>>>
>>>
>> Sweet.
>>
>> We worked on a mainframe clone of the IBM/370 running VM/370 (CP/CMS).
>> We used the FLACC compiler which was supposed to conform to the Revised
>> Report. It did have some debugging support but since we where students
>> and allowed only limited access to the mainframe we had to do without
>> such advanced features. Compile => fix compiler errors => repeat and
>> then compile => run => fix errors => repeat is about what we did.
>
> Been there, done it. Write ICL assembler (PLAN3) or COBOL on coding
> sheets, punch the cards yourself with a 12 key manual punch if time was
> short and then get one overnight compile&test run a day plus a lunchtime
> run if we were lucky and could operate the machine ourselves (this was
> pre-George 3). Use the punch again to fix errors and shuffle them into
> the pack. Still, even at that stage we were a little better off than IBM
> guys because we kept source on tape or disk long before most of them did
> and had card-driven line editors to fix the source in situ.
>
> But, tell this to the kids today ........
>
>

Things have changed a bit indeed...

I am glad I never had to use punch cards. We had a very advanced line 
editor named e not unlike Unix ed. The rest sounds painfully familiar.

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

#29433

On Tue, 29 Jul 2014 22:43:54 +0200, Silvio wrote:

> I am glad I never had to use punch cards. We had a very advanced line
> editor named e not unlike Unix ed. The rest sounds painfully familiar.
>
They had their advantages. 

Given a manual 12 key punch and an optical reader on the computer, making 
small corrections was easy. Punch a new hole or two, smooth chads into 
the unwanted hole(s) and stick the card back into the deck. If you had 
contact readers is was the same except yo put a scrap of sellotape over 
the unwanted hole...

Then again, they were great for shopping lists and bookmarks (there's 
even one or two rather dilapidated ones still living in my cookbook 
collection.

....and two cards and a pencil made a surprisingly good tailless glider.



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

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

#29372

On 7/27/2014 12:13 PM, 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.

class Foo {
   String name;

   public static void bar(String name) {
     Foo baz = new Foo();
     System.out.println(baz.name);
   }
}

Is that code stringifying baz and concatenating the result to the name 
parameter, or is it retrieving the name field of baz? How would you 
access the other variant?

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

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

#29408

On Sun, 27 Jul 2014 10:13:16 -0700, Roedy Green
<see_website@mindprod.com.invalid> 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.
>
>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.

     C does this for string literals.

Sincerely,

Gene Wirchenko

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

#29478

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:

I don't. It is already used for dereference.

a.b
a. b
a .b
a . b

Arne

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

#29505

On Thursday, July 31, 2014 10:07:40 PM UTC-5, Arne Vajhøj wrote:
> 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:
> 
> 
> 
> I don't. It is already used for dereference.
> 
> 
> 
> a.b
> 
> a. b
> 
> a .b
> 
> a . b
> 
> 
> 
> Arne

Agreed. String concatenation is already fine as is with +. Addition is left associative, so if you need to perform addition within a String concatenation, when in doubt use ( ) to force order of precedence of the math prior to concatenation. Or do what I do and perform math computations outside of concatenation, where it honestly has no business being IMO (I'm unaware of any reasonable performance benefits or readability benefits by performing addition and concatenation together).

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

#29336

On Thu, 24 Jul 2014 19:31:29 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote, quoted or indirectly quoted someone who said :

>A new concatenation operator would not solve that problem
>in all cases.

Assume there were two distinct + operators.

They might both have the same precedence, or perhaps addition would be
higher than concatenation (or even if the IDE just used two different
glyphs after it analysed).

Please show me a expression that would still be confusing.

If you used the new operators to express your intent, an expression
that is legal now, but gives the wrong result would become an illegal
expression.

-- 
Roedy Green Canadian Mind Products http://mindprod.com
Science is what we understand well enough to explain to a computer.
Art is everything else we do. 
~ Donald Ervin Knuth (born: 1938-01-10 age: 76)

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

#29353

On Sat, 26 Jul 2014 08:31:10 -0700, Roedy Green wrote:

> On Thu, 24 Jul 2014 19:31:29 -0400, Arne Vajhøj <arne@vajhoej.dk> wrote,
> quoted or indirectly quoted someone who said :
> 
>>A new concatenation operator would not solve that problem in all cases.
> 
> Assume there were two distinct + operators.
>
That's just operator overloading. Algol 68 explicitly allowed that. The 
following was how the standard operator for adding integers was defined 
in the Algol 68R standard prelude:

op + = (int a,b) int: ( a + b );

But its easy to overload. If we assume that the string mode was declared 
as:

mode string = [1: 0 flex]]char;

then we can overload + to concatenate two strings:

op + = (string a,b) string: 
                    begin string c; 
                          for i from lwb a to upb a do c[i] := a[i] od;
                          int n := upb c;
                          for i from lwb b to upb b do c[i+n] := b[i] od;
                          c;
                    end

The syntax may not be quite right (its been 37 years and I don't have a 
compiler to check it with), but in Algol 68R you could (and I did) 
overload any operator by declaring extensions in just that way. 
  
> If you used the new operators to express your intent, an expression that
> is legal now, but gives the wrong result would become an illegal
> expression.
>
It can be very elegant. There was am Algol 68R extension for defining and 
plotting 2D diagrams It used two base modes: a sketch (which was a 
plottable object but yet scaled or coloured, etc. and a picture, which 
was scaled and ready for output. There were also a number of predefined 
sketch extensions, e.g. circle, rectangle, text and a few more overloads 
for + so you could write something like this:

picture p = circle(3.0) + rectangle(3.5, 4.5) + text("Title");
print(p);

Easy to read and write or what?


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

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

#29366

On Sat, 26 Jul 2014 21:04:10 +0000 (UTC), Martin Gregorie
<martin@address-in-sig.invalid> wrote, quoted or indirectly quoted
someone who said :

>> 
>> Assume there were two distinct + operators.

What I mean by that is if concatenation and addition used visually
different operators.
 
You can take this too far. Long ago I vaguely call separate operators
for int and floating point in some language, maybe Act V.
-- 
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]

#29395

On Sat, 26 Jul 2014 21:04:10 +0000 (UTC), Martin Gregorie
<martin@address-in-sig.invalid> wrote, quoted or indirectly quoted
someone who said :

>op + = (int a,b) int: ( a + b );

The problem with that is when you have code mixing ordinary plus and
overloaded plus.  To understand the code you have to decode it to
figure out which operator is intended. This is not something you can
do when skimming.

On the other hand overloading is  a rich metaphor than helps simplify
the syntax. For example, compare a complex library implemented with
overloaded operators to one with methods.

I think the way to resolve this is to take advantage of the fact we
are no longer limited to ASCII teletypes. There are glyphs and fonts
and colours that look similar to ordinary plus, but which are easy to
tell apart. Use your IDE/SCID to do the visual decoding for you.
-- 
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]

#29412

On Mon, 28 Jul 2014 08:50:47 -0700, Roedy Green wrote:

> I think the way to resolve this is to take advantage of the fact we
> are no longer limited to ASCII teletypes. There are glyphs and fonts
> and colours that look similar to ordinary plus, but which are easy to
> tell apart. Use your IDE/SCID to do the visual decoding for you.

What do I use to type it ?

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

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

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

Back to top | Article view | comp.lang.java.programmer

csiph-web