[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 544 - trunk/subversion/bindings/java/jni/org/tigris/subversion/lib

From: Alexander Mueller <alex_at_littleblue.de>
Date: 2001-11-30 15:54:48 CET

"B. W. Fitzpatrick" schrieb:

> > On Wed, Nov 28, 2001 at 10:28:22AM -0800, Daniel Rall wrote:
> > > Alexander Mueller <alex@littleblue.de> writes:
> > >
> > > > there are several ways to implement data access with java. Hm. But
> > > > maybe you are right. I implemented the class the way I did to
> > > > improve performance. The variables do have the "final" statement, so
> > > > they cant be changed after creation of an instance.
> > >
> > > Hi Alex. I noticed the final keyword, but think accessor methods are
> > > really the way to go, as they are more Java-esque. Developers who
> > > work with Java regularly will be more familiar with an API which uses
> > > accessors, and also more likely to extend and integrate such an API
> > > (and the initial net effect will supply equivalent data access
> > > equivalent to the public final member variables).
> >
> > The accessors would be needless overhead. These are more like structures,
> > rather than objects that would be extended.
> >
> > IMO, keep 'em as attributes.
>
> I'm -1 on this. Structures or not, consistency is king, and reaching
> into another object and touching it's instance variables is not
> consistent with how you should be using Java in the first place, IMO.
>
> I vote +1 for accessors.
>
> -Fitz

Just on more comment from my side: touching it's instance variables is possible only to read values. Since they are
final variables they cant be wrote. This is the only case I ever would implement instance variables with public access.
They are semi-constant values because they dont change during the lifetime of the class....

Alex

P.S.: I will request a poll on this topic...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:50 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.