On 1 August 2012 18:09, Becksfort, Jared <jared.becksf...@stjude.org> wrote: > Gary, > > I have wondered about the public scoping of arrays myself for that same > reason. I also write image processing code, and the arrays can be quite > large, especially if the processing is in three dimensions.
A public get method that returns the array itself is not useful, but one can write a get(int entry) method that makes the array read-only. In an optimising compiler the code will likely be inlined to be no less efficient than direct access. The array-clone approach can also be useful, depending on the application. Mutable public data makes thorough testing much harder, as well as all the potential security and threading issues. > Jared > > -----Original Message----- > From: Gary Lucas [mailto:gwlu...@sonalysts.com] > Sent: Wednesday, August 01, 2012 12:01 PM > To: 'Commons Developers List' > Subject: My vote for release > > > Damjan, > > I just saw that you were soliciting votes for release. I think you've done > an outstanding job and I'm all for it. I would vote twice if I could :-) > > I saw that some of the folks on the Apache page were complaining about some > of the code-checking issues. I've never looked at these myself, but I suppose > that many of them are not worth fixing. > > For example, somebody complained that a class shouldn't have a publically > scoped array. Let's say a programmer tried to address that. If he writes a > "get" method that is a simple pass-through returning a reference to the > internal array, has he really added any security (meaning protection against > accidental misuse)? Of course not. Suppose, instead, that he writes a > method that makes a copy of the array before returning it. Now he's improved > security, but degraded the performance of the overall code... maybe > seriously. And in imaging processing, performance trumps security almost > every time. > > Anyway, if there are specific areas in the TIFF tree or elsewhere that you > would like me to review, please let me know and I'll be glad to take a look > at them. > > Gary > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > > > Email Disclaimer: www.stjude.org/emaildisclaimer > Consultation Disclaimer: www.stjude.org/consultationdisclaimer > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
