> > [...]
> >
> > P.S. Is there an occurrence in CM, where a method can be passed a null
> > argument?
>
> Yes. One example is the constructor for EmpiricalDistribution that
> takes a RandomGenerator as argument.
Thanks for finding one of those few examples.
The first remark (concerning the issue at hand in this thread) is that it is
enough to say in the documentation of those cases that "null" is allowed.
The policy is (would be) that "null" is never a valid argument (except in
the documented cases).
> If a null is supplied, the
> constructor does not complain and the lazy initialization works as
> though the argumentless constructor had been used and a JDK random
> generator is created.
The second remark is that allowing "null" in this case only brings confusion
because there also exists overloaded constructors. [Overloading is the right
way to provide default arguments; using "null" is to be avoided (and is a
remnant from C programming where no two methods can have the same name).]
We thus have
public EmpiricalDistribution(int binCount)
and
public EmpiricalDistribution(int binCount, RandomGenerator generator)
In the latter case, the doc says:
* @param generator random data generator (may be null, resulting in
* default JDK generator)
Which is also what happens in the former case, albeit a little later.
It's confusing because the word "lazy" does not appear anywhere, so there is
no usefulness (from the user's point-of-view) to pass null to the two-args
constructor, where he could use the more concise, one-arg, constructor.
Even if the doc would highlight the difference, it's still needlessly
complicated to allow "null" since the class's seemingly central method
"getNextValue" would trigger the initialization of the RNG sooner or later.
[Hence the gain of "lazy init" is nil.]
If there are use-cases where the RNG part of the functionality is never
used, then, IMHO, the design can be improved by separating the data loading
+ statistics computation from the actual distribution functionality
("getNextValue").
In the new product, there would be no reference to a RNG (thus vanished the
"can be null, and if it is, there will be lazy init etc.") in one class,
while in the other, "getNextValue" would indeed be so prominent that the
class cannot be used without a RNG (thus lazy init is totally useless) and
that argument _cannot_ be null.
> There are other similar examples, mostly
> constructors, IIRC.
Then a similar analysis probably applies.
Gilles
> Phil
> >
> >
> >> Phil
> >>
> >>> The second option cares for all the various positions _except_ the
> >>> singly-rooted hierarchy.
> >>>
> >>>
> >>> Regards,
> >>> Gilles
> >>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
