TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Subject:
From:
"W. Wesley Groleau x4923" <[log in to unmask]>
Date:
Thu, 1 Oct 1998 11:57:10 -0500
Reply-To:
"W. Wesley Groleau x4923" <[log in to unmask]>
Parts/Attachments:
text/plain (36 lines)
> I'd like to see some more context from Eckel's Chap. 3 section.
> Specifically, how does he introduce the aliasing issue for the case
> of Java? How does he define aliasing?

A more objective summary than what I just posted is:

In Java, almost everything is on the heap, and the names you manipulate
are really the names of the pointers.  So

   Number X;
   Number Y;
   ....
   X = Y

is (usually) equivalent to Ada's

   X : Number_Access_Type;
   Y : Number_Access_Type;
   ....
   X := Y;

Thus, a Java programmer has to think about aliasing almost continuously.

It's like telling an Ada programmer, "You are required to use access types
and the heap for anything larger than 32 bits.  And you are not allowed to
use ".all"   I'll tell you a workaround when the course is almost over."

Of course, much code will use the object's methods to change things, if
the object is well designed.  Perhaps I'll change my tune after more Java
experience, but at the moment, this seems counter-productive.

Eckel offers a FREE download of his book in PDF.  This is actually
more up-to-date than the published version.

http://www.BruceEckel.com     (his C++ book is also there)

ATOM RSS1 RSS2