As I said before, removing this method is the best option now. Get it
right in v8.
Stephen
On 27 January 2011 05:05, <mark.reinh...@oracle.com> wrote:
> Executive summary: requireNonNull is the preferred name.
>
>> Date: Tue, 25 Jan 2011 18:33:47 -0500
>> From: brian.go...@oracle.com
>
>> mark.reinh...@oracle.com wrote:
>>> I think requireNonNull(x) is confusing.
>>
>> Remember there's two versions of someModifierNonNull being discussed; the one
>> currently in Objects is the precondition-enforcing variety, not the
>> postcondition-ensuring variety. Are we talking about the same thing?
>
> Yes, i.e., the former.
>
>>> For those familiar with the "requires/ensures/modifies" triad of verbs as
>>> a compact way of identifying the preconditions, postconditions, and side
>>> effects of a method or procedure in a comment, a specification, or a more
>>> formal design-by-contract framework, "requires" is just wrong.
>>>
>>> When analyzing the invocation of foo in your example, the non-nullity of
>>> s and t are preconditions of foo and therefore postconditions of the
>>> check method. Naming the check method "requireNonNull" suggests that
>>> the check method itself has a precondition that its argument be non-null,
>>> when in fact it's the check method's postcondition which ensures that
>>> property.
>>>
>>> Since postconditions are labeled "ensures" in the "r/e/m" triad, this
>>> method should be named "ensureNonNull".
>>
>> Right, there's precedent for "ensureXxx" methods to actually change the state
>> of things to ensure the postcondition, such as ensureCapacity() methods in
>> the
>> collection implementations. Given that a part of the motivation for this
>> change was to leave room in the namespace for both the precondition-enforcing
>> variety (barf on null) and the postcondition-ensuring variety, aka the
>> carpet-sweeping variety ("if it is null, make it non-null") ensureNonNull
>> sounds a lot more like the the carpet-sweeping version than the version being
>> discussed (barf on null).
>
> I was actually arguing that the barfing version should be named
> ensureNonNull.
>
> (Wow, am I actually writing about barfing methods?)
>
>> The r/e/m framework seems to support require for the throwing version (as
>> implemented by this patch): for the throwing version, non-nullity is a
>> precondition of the check method (if the condition is not met, error),
>> whereas
>> for the carpet-sweeping version, it is a postcondition of the check method
>> (if
>> the check method can come up with a reasonable default value). (It happens
>> to
>> be a postcondition of both, but the significant behavior and use of the
>> throwing version currently in Objects is to enforce an error when the
>> precondition is not met.) Therefore:
>>
>> requireNonNull(x) -> throw if x == null
>> ensureNonNull(x) -> convert x to a non-null value if null
>>
>> seems like the right taxonomy.
>
> It depends on your perspective.
>
> In a nested method invocation, the postconditions of the inner method
> must relate to the preconditions of the outer method. That is, for the
> expression
>
> foo(bar(x))
>
> to be correct then the postconditions of the bar method must imply the
> preconditions of foo method.
>
> Now suppose that bar is intended to be the barf-on-null method.
>
> If we consider how to name bar on its own, outside of its intended usage
> as in this example, then it's natural (for me, anyway) to conclude that
> "ensuresNonNull" is the right name. What's important about bar is its
> postcondition, namely that its return value (x) is not null. Naming it
> "requireNonNull" seems backwards on this view, because "requires" is
> always about preconditions, and it's definitely not a precondition of
> this method that its argument not be null.
>
> If, by contrast, we consider how to name bar in the context of the above
> example then it's easy to see that "requireNonNull" is the better name,
> because what's important in the overall expression is satisfying foo's
> precondition that its argument not be null, and so
>
> foo(requireNonNull(x))
>
> reads very fluently.
>
> A little utility method like this will never (well, hardly ever) be used
> in isolation, so I agree now that it makes sense to prefer the second
> form, i.e., requireNonNull.
>
> I'm not sure I agree that the corresponding carpet-sweeping method is
> best named ensureNonNull; treating that as a conversion, i.e., asNonNull,
> may be a better choice. That, however, is a discussion for another
> release.
>
> - Mark
>
