On 9/10/12 3:44 AM, Gilles Sadowski wrote:
>>> [...]
>>>
>>> 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.
Good, we agree there.
>
> The policy is (would be) that "null" is never a valid argument (except in
> the documented cases).
I agree there. Where we disagree is what we should do when an
illegal null argument is passed to an API that does not accept
nulls. I like to document and throw IAE in this case (per
guidelines in the Developers Guide). That is more robust, since
failure is immediate, there are no potential downstream impacts /
resource utilization / leakage potential, and it is easier to debug
/ trace without looking at the source code, especially if an
informative message indicating what precondition failed is provided.
>
>> 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).]
I am sure you can figure out how to refactor my applications that
use this functionality, but here an example showing why it exists.
When initializing an application from external configuration
meta-data, if a RandomGenerator class is provided in the config, the
initialization framework creates an instance of the provided class
and sets a property of an application class being created equal to
the instance. This property is used by constructors of other
members of the class. If no config is provided for the
RandomGenerator, the property is null. The null-safe constructor
allows the property to be used as an argument to the constructor,
avoiding the need to code (or configure) the test for null in
initialization.
>
> 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.
See use case above - when what is being passed in is a property,
which may be null, it is convenient to be able to provide null to
the constructor.
Phil
>
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
