Newsgroups: comp.lang.java,comp.object,comp.object.logic
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!gatech!newsfeed.internetmci.com!chi-news.cic.net!ddsw1!news.mcs.net!idm.com!mongo.idm.com!plb
From: plb@idm.com (Peris Brodsky)
Subject: Re: Java public instance variables harmful?
Sender: news@idm.com (The News User)
Message-ID: <Do28qp.IqL@idm.com>
Date: Sun, 10 Mar 1996 16:35:12 GMT
References: <KRUSE.96Mar6131047@cms6.cern.ch> <4hkhnv$5ne@decaxp.harvard.edu>
Nntp-Posting-Host: mongo.idm.com
Organization: Information Data Management
X-Newsreader: TIN [version 1.2 PL2]
Lines: 35
Xref: glinda.oz.cs.cmu.edu comp.lang.java:30332 comp.object:45603 comp.object.logic:735

Keith Robison (robison@mito.harvard.edu) wrote:
> Andres Kruse (kruse@cms6.cern.ch) wrote:

> : Hi Everyone,

> : this is a question concerning the design of the Java language,
> : I asked a similar yesterday with overwhelming (none) response
> : in comp.lang.java.. so here I go again:

> : I feel that there is a missing feature in the Java language design,
> : but maybe it's just me who doesn't understand it correctly, maybe
> : it's already there..

> :   The fact that instance variables can be made public seems very
> : dangerous and IMHO it's clearly against the idea of encapsulation.
> :   But, that wouldn't be such a big problem if there was a way to
> : sort of fake a public instance variable through an access method.

> IMHO it is rather a bad idea to add a possibly complicated idea
> to the language to allow folks to cover their bad OO design.
>   
> If you have no public instance variables and use methods to get & 
> set values, it gives much more control & future flexibility.  
> It's too bad the AWT designers have already set such a poor example
> with Point, Dimension, Rectangle, etc.

It DOES set a bad example, esp. considering the OOD acumen of
the average Java hacker out there, but its justified for such
primitive classes as these.  When will Point.x and Point.y ever
disappear as integral fields?  I'm willing to risk it in exchange for
a faster graphics-intensive application.

Peris L. Brodsky
IDM, Inc.
plb@idm.com
