commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
Subject Re: Class I would like to commit to commons Collections
Date Tue, 04 Sep 2007 03:30:26 GMT
Sorry, but I read and replied to that email before I had my morning
coffee, so I may have been a bit grumpy myself.

I think that if you don't supply the map that's going to be returned,
then it should be "toMap".  If you do, then you're really asking to
fill the map.  To me, that naming convention alleviates confusion
about what's going on with the input map.

For the most part, I think folks do use HashMap as the default.
That's just my $0.02.


On 9/3/07, Stephen Kestle <stephen.kestle@orionhealth.com> wrote:
> 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
> <K,V> Map<K,V> *Map(Collection<V> c, Transformer<V,K> 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<C, K,V> CollectionUtils.toMap(Collection<C> input,
> > Transformer<C,K> keyTransformer, Transformer<C,V> valueTransformer,
> > Map<K,V> 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 <C,K,V> being the type
> > variables of the method itself):
> >
> > <C,K,V> Map<K,V> CollectionUtils.toMap(Collection<C> input,
> > Transformer<C,K> keyTransformer, Transformer<C,V> valueTransformer,
> > Map<K,V> map);
> >
> > So, the actual method might look like:
> >
> > public static <C,K,V> Map<K,V> toMap(Collection<C> input,
> >      Transformer<C,K> keyTransformer,
> >      Transformer<C,V> valueTransformer,
> >      Map<K,V> map)
> > {
> >   for (C c : input)
> >   {
> >     map.put(keyTransformer.transform(c), valueTransformer.transform(c));
> >   }
> >   return map;
> > }
> >
> > If you put "Map<C,K,V>" 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 <stephen.kestle@orionhealth.com> 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<C,K> and Transformer<C,V>
that
> >> transform the collection input type to the respective map key, value types.
> >>
> >> The second signature only has <K,V> as there is no value transformer,
so
> >> the input collection is the type of value.
> >>
> >> Cheers
> >>
> >> Stephen
> >>
> >> James Carman wrote:
> >>
> >>> What is "Map<C,K,V>" here?  The Map interface only has two type
> >>> parameters, right?  Shouldn't it just be Map<K,V>?
> >>>
> >>> On 8/29/07, *Stephen Kestle * <stephen.kestle@orionhealth.com
> >>> <mailto:stephen.kestle@orionhealth.com>> 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<C, K,V> CollectionUtils.toMap(Collection<C> input,
> >>>     Transformer<C,K> keyTransformer, Transformer<C,V>
> >>>     valueTransformer, Map<K,V> 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<K,V> CollectionUtils.toMap(Collection<V> input,
> >>>     Transformer<V,K> keyTransformer){
> >>>          return toMap(input, keyTransformer, NOPTransformer, new
> >>>     HashMap<K,V>());
> >>>     }
> >>>
> >>>     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 <mailto:dev-unsubscribe@commons.apache.org>
> >>>>     For additional commands, e-mail: dev-help@commons.apache.org <mailto:dev-help@commons.apache.org>
> >>>>
> >>>     --
> >>>     ------------------------------------------------------------------------
> >>>     * <http://www.orionhealth.com>*
> >>>
> >>>
> >>>
> >>>     *Stephen Kestle Software Engineer*
> >>>     stephen.kestle@orionhealth.com <mailto:stephen.kestle@orionhealth.com>
> >>>     P: +64 9 638 0619
> >>>     M: +64 27 453 7853
> >>>     F: +64 9 638 0699
> >>>     S: skestle
> >>>     www.orionhealth.com <http://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.
> >>>
> >>>
> >>>
> >> --
> >> ------------------------------------------------------------------------
> >> * <http://www.orionhealth.com>*
> >>
> >>
> >>
> >> *Stephen Kestle Software Engineer*
> >> stephen.kestle@orionhealth.com <mailto:stephen.kestle@orionhealth.com>
> >> P: +64 9 638 0619
> >> M: +64 27 453 7853
> >> F: +64 9 638 0699
> >> S: skestle <callto:skestle>
> >> www.orionhealth.com <http://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
> >
> >
>
> --
> ------------------------------------------------------------------------
> * <http://www.orionhealth.com>*
>
>
>
> *Stephen Kestle Software Engineer*
> stephen.kestle@orionhealth.com <mailto:stephen.kestle@orionhealth.com>
> P: +64 9 638 0619
> M: +64 27 453 7853
> F: +64 9 638 0699
> S: skestle <callto:skestle>
> www.orionhealth.com <http://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


Mime
View raw message