On Nov 6, 2011, at 2:50 PM, Gilles Sadowski <gil...@harfang.homelinux.org>
wrote:
>> [...]
>>> 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].
Then please just leave it alone.
Phil
> 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-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
