commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: My vote for release
Date Thu, 02 Aug 2012 17:03:07 GMT
On 1 August 2012 18:09, Becksfort, Jared <Jared.Becksfort@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:gwlucas@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
> Email Disclaimer:  www.stjude.org/emaildisclaimer
> Consultation Disclaimer:  www.stjude.org/consultationdisclaimer
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message