TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Mime-Version:
1.0
Sender:
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
X-To:
Michael Feldman <[log in to unmask]>
Date:
Thu, 1 Oct 1998 14:05:11 -0700
Reply-To:
Ben Brosgol <[log in to unmask]>
Subject:
From:
Ben Brosgol <[log in to unmask]>
X-cc:
"Ben.Brosgol" <[log in to unmask]>
Content-Transfer-Encoding:
7bit
Content-Type:
text/plain; charset="iso-8859-1"
Parts/Attachments:
text/plain (43 lines)
Mike Feldman wrote:

>I must say that in the "pure OO" business, he's probably right that one
>should avoid assignment, relying instead on method invocations.
>Assignment should be nearly unnecessary.

Method invocations in Java do "pass by copy", which is semantically
equivalent to assignment.  When one is invoking a method and passing a
reference to an object, the formal parameter will be referencing the same
object.  This is a nasty problem in Java since one cannot constrain the
method to have "readonly" access to the referenced object.  If, through
error or intent, the referenced object is changed through the formal, then
this change will be reflected in the actual parameter after the return.
(With respect to preventing errors, Ada does it better with "in" mode
parameters of "by reference" types such as tagged types, although "access
constant" parameters would be a nice feature too.)

So perhaps Eckel was introducing "reference assignment" as the primitive
concept, using it as the basis for explaining parameter passing later in the
book.  Sounds like a not-unreasonable approach, especially since some
popular classes like String allow only "immutable" objects (ie, objects
whose values never change after they've been constructed), so the sharing
intrinsic in assignment doesn't cause "indirect update" problems.  Of course
there is the companion issue that "==" does reference comparison, so if
assignment is introduced early then the difference between "==" and equals()
likewise needs to be covered (and that leads to the slipperly slope with
clonability).

All in all, Java is not an easy language to teach to people who are not
already aware of the fundamentals of pointers and all its implications.
Ada is easier to teach; for more details on this comparison, wait for the
next issue of SIGAda's Ada Letters -- I assume that all subscribers to this
group are SIGAda members, if not, send me a note and I'll let you know how
to correct this error of omission -- which reprints the proceedings of last
summer's ASEET conference.  I presented a paper there contrasting Ada and
Java as a "foundations" language in a  computer science curriculum.

Regards,

Ben Brosgol
Aonix
[log in to unmask]

ATOM RSS1 RSS2