commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: [PATCH] [collections] new: MapUtils#asMap(Object[]) and MapUtils#toMapEntry(Object)
Date Sat, 12 Oct 2002 21:38:06 GMT
From: "Moritz Petersen" <>
> Sorry, that I forgot to send the test case together with the first
> mail. A typical newbie mistake, I guess.

Thats OK, but we would definitely prefer them as attachments as the mail
system messes up the lines otherwise ;-)
> To summarize the pros and cons:
> asMap                | toMap
> -------------------------------------------
> creates a new        | creates a new
> instance             | instance of a
>                       | wrapper class
> -------------------------------------------
> populates the new    | accesses the backing
> instance in the      | array only on demand
> moment it is created |
> -------------------------------------------
> If I am not wrong, the advantage of the to... methods is, that the
> wrapper class is backed up by the array, and will access its elements
> only on demand.(?)

Part of the confusion is that you've swapped the names around. The method
you've coded should be called toMap, not asMap.

The terms have meanings as follows:
'to' - convert an object from one type to another leaving the original
'as' - provide a view of an object as another type, changes to the original
are thus seen through the view

The asMap method will require a new inner class within MapUtils. Its
operation is similar to Collections.asList from the JDK.

> Another word about the toMapEntry() method. Maybe it should be renamed
> to asMapEntry(). The reason why it is called toMapEntry() is, that I in
> fact created a wrapper class, that implemented the Map.Entry interface.
> But then I realized, that there is already a DefaultMapEntry class,
> which I could use. So I exchanged my anonymous inner class with the
> DefaultMapEntry.

I think that DefaultMapEntry is a JDK1.4 class. Also, I wouldn't support
adding toMapEntry as a public method. My suggestion would be to merge
toMapEntry into toMap, thus removing the need to reference DefaultMapEntry,
and removing a temporary object creation.


PS. I am trying to organise a release at present, so the patch probably
won't get committed until that is done.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message