Return-Path: 
 <commons-dev-return-91217-apmail-jakarta-commons-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org
Received: (qmail 13087 invoked from network); 14 Jul 2006 09:26:37 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 14 Jul 2006 09:26:37 -0000
Received: (qmail 63214 invoked by uid 500); 14 Jul 2006 09:26:34 -0000
Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org
Received: (qmail 62627 invoked by uid 500); 14 Jul 2006 09:26:33 -0000
Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:commons-dev-unsubscribe@jakarta.apache.org>
List-Help: <mailto:commons-dev-help@jakarta.apache.org>
List-Post: <mailto:commons-dev@jakarta.apache.org>
List-Id: "Jakarta Commons Developers List" <commons-dev.jakarta.apache.org>
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Delivered-To: mailing list commons-dev@jakarta.apache.org
Received: (qmail 62615 invoked by uid 99); 14 Jul 2006 09:26:33 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 Jul 2006 02:26:33 -0700
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received: from [209.237.227.198] (HELO brutus.apache.org) (209.237.227.198)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 Jul 2006 02:26:32 -0700
Received: from brutus (localhost [127.0.0.1])
	by brutus.apache.org (Postfix) with ESMTP id 4A9F4410607
	for <commons-dev@jakarta.apache.org>; Fri, 14 Jul 2006 09:24:31 +0000 (GMT)
Message-ID: <11981188.1152869071302.JavaMail.jira@brutus>
Date: Fri, 14 Jul 2006 09:24:31 +0000 (GMT+00:00)
From: "Hendrik Maryns (JIRA)" <jira@apache.org>
To: commons-dev@jakarta.apache.org
Subject: [jira] Commented: (COLLECTIONS-215) Javadoc in DefaultedMap very
 inconsistent
In-Reply-To: <16242897.1152196469820.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

    [ http://issues.apache.org/jira/browse/COLLECTIONS-215?page=comments#action_12421046 ] 

Hendrik Maryns commented on COLLECTIONS-215:
--------------------------------------------

I don't see a reason not to add the extra constructors.  They do seem useful.  Then you can explicitly state in their javadoc the behaviour of the get method.  Because if you only read the class javadoc, and one actually wants to have a transformer returned as default object instead of it being used, the class is unusable, even more, it does not comply to the spec.

And there is one more javadoc inconsistency you overlooked: 

-     * @throws IllegalArgumentException if map or transformer is null

+     * @throws IllegalArgumentException if map or value is null

      */

     protected DefaultedMap(Map map, Object value) {

<rant> Why do you (pl.) have this habit of making everything protected, it makes it so difficult to fix things and makes for much more complicated code! </rant>

> Javadoc in DefaultedMap very inconsistent
> -----------------------------------------
>
>          Key: COLLECTIONS-215
>          URL: http://issues.apache.org/jira/browse/COLLECTIONS-215
>      Project: Commons Collections
>         Type: Improvement

>     Versions: 3.2
>     Reporter: Hendrik Maryns
>     Assignee: Stephen Colebourne
>      Fix For: 3.3
>  Attachments: DefaultedMap.diff
>
> The javadocs in DefaultedMap is very inconsistent.  It speaks
> of factory
>  when a transformer is meant, it speaks of transformer when value is
>  meant and that sort of stuff. 
>  
>  Besides, it would be much cleaner to declare 'value' of type
>  Transformer, and create a transformer every time, except when one is
>  passed (the instanceof checks are wrong anyway), (I'd rename it to
>  transformer, too). 
>  
>  Even nicer would be to split up the constructor(s) into one
>  that takes a
>  value, and one that takes a Transformer, no instanceof checks needed,
>  much cleaner code, generification is almost trivial  :-) 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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