commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <gil...@harfang.homelinux.org>
Subject Re: [math] RandomDataImpl refactoring
Date Sun, 06 Nov 2011 21:50:58 GMT
> [...]
> > 1. Luc "was happy removing all the stuff".
> > 2. Sebb was inclined to make the field final.
> > 3. I agree with both.
> > That's three to one, if I count correctly.
> >
> > I don't have a big problem with keeping the functionality, if you insist on
> > that point.
> > I just suggested that it should stand out for what it is: syntactic sugar.
> 
> Look at the code for nextSecureHex.  That is not just "sugar."  Your
> opinion of what is "sugar" is just that - your opinion.

When I'm talking about sugar, I'm not referring to the code of the
"nextSecure..." methods (wich I had looked at before commenting, mind you).
It was in reference to code like:
---
    public void setSecureAlgorithm(String algorithm, String provider)
            throws NoSuchAlgorithmException, NoSuchProviderException {
        secRand = SecureRandom.getInstance(algorithm, provider);
    }
---
I thought I had made that clear at the beginning of the discussion.

> I would
> prefer not to have to rewrite that code in my applications.  It is
> not "sugar" to me or anyone else who is using it.  There are lots of
> funny little functions in what used to be MathUtils and the whole
> raft of Function stuff that I did not complain about because I
> assume you or others found them useful.  I don't think it is
> valuable or productive to start arguing about this now.  Please just
> accept the fact that this useful functionality has been there since
> 1.0 and it is not going to be dropped.

It seems that you don't care to read what I write.
I was not the one to suggested to drop, and I've just repeated, only 3 or 4
times, that it could as well stay. My position is based, as usual, on design
consistency. Your position is to negate any validity to others's arguments
on the sole basis that the stuff has been there for a long time.
As for the rest of the discussions on development, "old" is not a synonym for
"good".
It seems that your only argument thus far is to not have to change the way
you call that functionality from your personal code.
Where did you see that somebody asked you to rewrite this code?

I'm eager to know which "funny little functions" you are referring to.
Please compare what is comparable: What is in "MathUtils" (and its
replacements) is used _inside_ CM to avoid code duplication. If that's not
the case, I'd be the first to agree to remove it. It was all there
before my time.

Same for the functions-related stuff, except that it was all bundled in a
single class, and much less easy to use for those who'd be interested to
deal with functions objects. Moreover, there were function objects scattered
in several parts of CM, some of them with inconsistent interfaces or ad-hoc
definitions. [Code rationalization makes for code easier to grasp. It was/is
blatant that different parts of CM were written by different persons with
different coding styles (and I'm not talking of the basic formatting which
CheckStyle would complain about).]
Personally, I use only a few of those functions but, out of consistency,
I try to achieve the same level of completeness for all of them.

These are all tiny change contributions which you probably dismiss as
unnecessary, but my opinion (yes, it's just my opinion) is that a library
cannot survive just by piling up new functionalities without regard to
comprehensive design consistency.

> > IMHO, this alone makes the thing easier to use because you don't have to
> > have such a long explanation as currently exists in "RandomDataImpl" to make
> > the distinction between secure and non-secure.
> > With the refactoring, you can just state: "Application that require secure
> > RNG should use the {@link SecureRandomData} class". And in that class, you
> > give example of situations where the stuff could be useful (like session
> > IDs) without polluting a class like "RandomData".
> > I must add that you are yourself making a point that the utilities are
> > different, when stating that "secure" RNGs are "slow" to initialize.
> > And there are other properties (non-deterministic) that might make them
> > unsuitable for scientific usage.
> > Separation would go a good deal towards self-documenting code, thus _better_
> > documented code. [Say, people who wouldn't know CM, would readily spot a
> > class named "SecureRandomData". Being in line with the design of the Java
> > standard hierarchy for this stuff makes it also easier.]
> 
> I would like to hear from some actual users before changing this.

If you don't hear from them, maybe it is because you are the only user
(which should probably tell you something of how "broadly" useful the
functionality is)...

Personally, I have _zero_ stake in this issue because I don't use
"RandomDataImpl"[1].  I just try to point to a possible improvement of the
CM library, for its own sake.


Gilles

[1] More exactly, I used it indirectly, through the "sample" method of the
    "NormalDistributionImpl" (cf. MATH-701).

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


Mime
View raw message