Re: svn commit: r480849 -

["Henning P. Schmiedehausen" <hp...@intermeta.de>]

"Nathan Bubna" <nb...@gmail.com> writes:

Hm. Yes, that is a reason but it sounds a bit "dragged by the hair" to
me. An empty toolbox does not behave any different from a "non
existing toolbox" at all, so why keeping the difference artificially
alife?

Having a contract that ensures that the object is never null, allows
you to remove a number of "is null" checks from the code, thus
actually speeding up the often used pathes.

	Best regards
		Henning



>technically, it would be an empty map not empty list, but even so, i'm
>not sure about this.  if we can say for sure that no one (especially
>us) will ever want to tell the difference between an empty toolbox and
>no toolbox being set, then it would be marginally simpler to ensure
>that toolbox is never null.

>at this point, it's not a great burden to always test for the
>toolbox's presence and potentially provides more a more useful
>interface.

>in other words, i'll think about this...

>On 11/30/06, Henning P. Schmiedehausen <hp...@intermeta.de> wrote:
>> nbubna@apache.org writes:
>>
>> >+    public Map getToolbox()
>> >+    {
>> >+        if (this.toolbox != null)
>> >+        {
>> >+            return Collections.unmodifiableMap(this.toolbox);
>> >+        }
>>
>> Wouldn't it be better (and probably remove a lot of these tests) to make sure
>> that the toolbox can never be null (but contains an empty List?).
>>
>> >+        return null;
>> >     }
>>
>> I'd prefer Collections.EMPTY_LIST. Removes the necessity of always
>> checking for null.
>>
>>         Best regards
>>                 Henning
>>
>> --
>> Henning P. Schmiedehausen  -- hps@intermeta.de | J2EE, Linux,
>> 91054 Buckenhof, Germany   -- +49 9131 506540 | Apache person
>> Open Source Consulting, Development, Design | Velocity - Turbine guy
>>
>>           "Save the cheerleader. Save the world."
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: dev-help@velocity.apache.org
>>
>>

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

-- 
Henning P. Schmiedehausen  -- hps@intermeta.de | J2EE, Linux,
91054 Buckenhof, Germany   -- +49 9131 506540 | Apache person
Open Source Consulting, Development, Design | Velocity - Turbine guy

          "Save the cheerleader. Save the world."

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