Return-Path: Delivered-To: apmail-commons-dev-archive@www.apache.org Received: (qmail 14509 invoked from network); 4 Sep 2007 02:28:28 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Sep 2007 02:28:28 -0000 Received: (qmail 92971 invoked by uid 500); 4 Sep 2007 02:28:14 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 92910 invoked by uid 500); 4 Sep 2007 02:28:14 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 92896 invoked by uid 99); 4 Sep 2007 02:28:14 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Sep 2007 19:28:14 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [202.37.75.101] (HELO zeus.orion.co.nz) (202.37.75.101) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Sep 2007 02:29:19 +0000 Received: from mail.orionhealth.com ([172.20.0.2]) by zeus.orion.co.nz (8.12.10/8.12.10) with ESMTP id l842W0P2024780 for ; Tue, 4 Sep 2007 14:32:00 +1200 Received: from [172.20.4.105] (stephenk.orion.internal [::ffff:172.20.4.105]) by mail.orionhealth.com with ESMTP; Tue, 04 Sep 2007 14:27:14 +1200 Message-ID: <46DCC2A6.1080109@orionhealth.com> Date: Tue, 04 Sep 2007 14:27:50 +1200 From: Stephen Kestle Reply-To: stephen.kestle@orionhealth.com User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jakarta Commons Developers List Subject: Re: Class I would like to commit to commons Collections References: <20070829033845.3C505AB41FE@vmgump.apache.org> <46D544E3.20504@txttools.co.uk> <46D60142.2030905@orionhealth.com> <46DB29CB.3030207@orionhealth.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.7/4137/Tue Sep 4 00:17:24 2007 on zeus.orion.co.nz X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Virus-Checked: Checked by ClamAV on apache.org X-Old-Spam-Status: No, hits=-106.5 required=5.0 tests=BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT,USER_IN_WHITELIST autolearn=ham version=2.55 Ok - my bad. Jsut as you can raed tihs snenecte wtouiht tkiinhng (smoe-waht), so I read the method sig. BTW, I wasn't being condesending, just attempting to be considerate. Honestly, no bad/hard feelings. Anyhow, fillMap seems nice. However, would the simple Map *Map(Collection c, Transformer keyTransformer) be fillMap or toMap? I think at least the 3 I've proposed would be handy - I personally use LazyMaps a bit... I don't think (collection, keyTransformer, valueTransformer) would be super necessary - can just use one more param. Although... with generics, that could be verbose. Also, would I be correct in assuming that HashMap is the "default" Map implementation that people use? Cheers Stephen James Carman wrote: > Mr. Kestle, > > "Map CollectionUtils.toMap(Collection input, > Transformer keyTransformer, Transformer valueTransformer, > Map map)" > > I wouldn't usually reply, in the hopes that you put your code through > a compiler and apologize for being condescending all by yourself, > but... > > What I think you meant to type was (with being the type > variables of the method itself): > > Map CollectionUtils.toMap(Collection input, > Transformer keyTransformer, Transformer valueTransformer, > Map map); > > So, the actual method might look like: > > public static Map toMap(Collection input, > Transformer keyTransformer, > Transformer valueTransformer, > Map map) > { > for (C c : input) > { > map.put(keyTransformer.transform(c), valueTransformer.transform(c)); > } > return map; > } > > If you put "Map" in your code, the compiler will complain with > the error message "wrong number of type arguments; required 2." > > I might also change the method's name to "fillMap" rather than "toMap" > as it seems more descriptive of what you're doing. If it were toMap, > I wouldn't expect the input map to be there at all. The transformer > type parameters would give you enough type safety and you could just > instantiate a HashMap or something to return it. > > On 9/2/07, Stephen Kestle wrote: > >> I wouldn't usually reply, in the hopes that you re-read the method >> signature... >> C is the input collection >> K,V are the usual types for map >> There are two transformers Transformer and Transformer that >> transform the collection input type to the respective map key, value types. >> >> The second signature only has as there is no value transformer, so >> the input collection is the type of value. >> >> Cheers >> >> Stephen >> >> James Carman wrote: >> >>> What is "Map" here? The Map interface only has two type >>> parameters, right? Shouldn't it just be Map? >>> >>> On 8/29/07, *Stephen Kestle * >> > wrote: >>> >>> Hi John, >>> >>> I have not opened a ticket yet, but ... I have had very similar >>> requirements, and will [most-likely] be putting something in that >>> will solve your problem. >>> >>> However, it will not be a class - consider this method >>> >>> Map CollectionUtils.toMap(Collection input, >>> Transformer keyTransformer, Transformer >>> valueTransformer, Map map) >>> >>> You could then do what you wanted, passing in your integer >>> transformer for the key, and potentially MultiHashMap for the map. >>> >>> NB - this is in an ideal (and we're heading to that) collections >>> world. MultiHashMap will need to be changed to extend map >>> properly and implement the interface in a consistent way (not >>> breaking Map contract etc). >>> >>> Also note that there will be other variations on the method - most >>> commonly >>> >>> Map CollectionUtils.toMap(Collection input, >>> Transformer keyTransformer){ >>> return toMap(input, keyTransformer, NOPTransformer, new >>> HashMap()); >>> } >>> >>> I'll raise a ticket within the next few days - watch this list! >>> >>> Cheers >>> >>> Stephen >>> >>> John wrote: >>> >>>> Hi, >>>> >>>> I'm new to the collections mailing list and I have a class I >>>> think would be appropriate to be donated to the collections API. >>>> >>>> This is an extension of the MultiHashMap and filters a given >>>> Collection by a given field. It will put the objects into the map >>>> using the field value as the key. >>>> >>>> For example, lets say I have a class X which has an integer i. I >>>> have four instances of X each with the following names and values >>>> of i. >>>> >>>> x1 i=1 >>>> x2 i=2 >>>> x3 i=2 >>>> x4 i=5 >>>> >>>> The resulting MultiHashMap will contain the following after a >>>> call to >>>> sortCollection(X.class, "i"); has been made. >>>> >>>> key | Objects >>>> 1 | x1 >>>> 2 | x2, x3 >>>> 5 | x4 >>>> >>>> I can then get a Collection of sorted objects by asking the map >>>> for the key value. I find this very useful in many situations I >>>> have come across. I will of course make the required doc, package >>>> and src formatting changes to the class before submitting it. >>>> >>>> Please can you take a look and tell me if it is worth committing >>>> this to the Collections repository. What is the process I need to >>>> go through before committing? I'm a bit pressed for time at the >>>> mo' so I can't really spend too much time working on the >>>> Collections API as a regular developer. I am a big fan of the >>>> commons Collections API and commons project in general, just wish >>>> I had more time to get involved. >>>> >>>> Kind regards, >>>> >>>> John Hunsley. >>>> Technical Supervisor, Cy-nap Ltd. >>>> ------------------------------------------------------------------------ >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: >>>> dev-unsubscribe@commons.apache.org >>>> For additional commands, e-mail: dev-help@commons.apache.org >>>> >>> -- >>> ------------------------------------------------------------------------ >>> * * >>> >>> >>> >>> *Stephen Kestle Software Engineer* >>> stephen.kestle@orionhealth.com >>> P: +64 9 638 0619 >>> M: +64 27 453 7853 >>> F: +64 9 638 0699 >>> S: skestle >>> www.orionhealth.com >>> >>> >>> This e-mail and any attachments are intended only for the person >>> to whom it is addressed and may contain privileged, proprietary, >>> or other data protected from disclosure under applicable law. If >>> you are not the addressee or the person responsible for delivering >>> this to the addressee you are hereby notified that reading, >>> copying or distributing this transmission is prohibited. If you >>> have received this e-mail in error, please telephone us >>> immediately and remove all copies of it from your system. Thank >>> you for your co-operation. >>> >>> >>> >> -- >> ------------------------------------------------------------------------ >> * * >> >> >> >> *Stephen Kestle Software Engineer* >> stephen.kestle@orionhealth.com >> P: +64 9 638 0619 >> M: +64 27 453 7853 >> F: +64 9 638 0699 >> S: skestle >> www.orionhealth.com >> >> >> This e-mail and any attachments are intended only for the person to whom >> it is addressed and may contain privileged, proprietary, or other data >> protected from disclosure under applicable law. If you are not the >> addressee or the person responsible for delivering this to the addressee >> you are hereby notified that reading, copying or distributing this >> transmission is prohibited. If you have received this e-mail in error, >> please telephone us immediately and remove all copies of it from your >> system. Thank you for your co-operation. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org >> For additional commands, e-mail: dev-help@commons.apache.org >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org > For additional commands, e-mail: dev-help@commons.apache.org > > -- ------------------------------------------------------------------------ * * *Stephen Kestle Software Engineer* stephen.kestle@orionhealth.com P: +64 9 638 0619 M: +64 27 453 7853 F: +64 9 638 0699 S: skestle www.orionhealth.com This e-mail and any attachments are intended only for the person to whom it is addressed and may contain privileged, proprietary, or other data protected from disclosure under applicable law. If you are not the addressee or the person responsible for delivering this to the addressee you are hereby notified that reading, copying or distributing this transmission is prohibited. If you have received this e-mail in error, please telephone us immediately and remove all copies of it from your system. Thank you for your co-operation. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org For additional commands, e-mail: dev-help@commons.apache.org