[Opinions from [lang] committers desired, on inclusion of asMap into
ArrayUtils]
I believe that this difficulty is the reason why asMap(Object[]) was never
included in the JDK, but toMap() was.
Here is my solution:
- Hashing - document the behaviour, stating that the Map will behave poorly
as its size grows. And that it returns the first matched key.
- Changing the underlying objects - the best solution I can think of is to
treat what we have previously considered invalid values as both key and
value. Thus
new Object[] {null, "abba", new Object[] {"foo", "bar"}}
has 3 key value entries:
null -> null
"abba" -> "abba"
"foo" -> "bar"
This way, the Map contents are always valid (ignoring the duplicate keys
issue, which cannot be solved)
- values, entrySet, keySet, iterator - implemented as best per the spec
However, before any work occurs, I'd like to ask other [lang] committers if
they agree that such a beast is still useful, or whether it is too loose.
Stephen
----- Original Message -----
From: "Moritz Petersen" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
Sent: Monday, October 14, 2002 10:59 AM
Subject: RE: [lang] ArrayUtils toMap asMap, [was Re: [collections] [PATCH]
MapUtil]
> Stephen,
>
>
> > By comparison with the JDK, the method asList(Object[]) is on
> > Arrays. Thus I
> > have applied the patch to ArrayUtils in [lang] instead of [collections].
>
> you're right, that makes sense.
>
> > When I looked at asMap(Object[]) I discovered certain problems that we
> > hadn't considered:
> > - the array doesn't behave like a Map when looking up keys because its
not
> > hashed
>
> Problem with this is, that asMap() returns the 'ArrayMap' object, that
just
> accesses the backup array. Hashing the keys would mean to create a new
> hashed representation of the array, and to keep it in sync with the actual
> keys. The question is, if it is worth it.
>
>
> > - what happens if someone changes the underlying array, to put an
illegal
> > object type or null into the array
>
> Operations on the array may be dangerous, after calling asMap(). Because
the
> returned ArrayMap is evaluated lazy, changes to the array are handled the
> same way as if they have been inside before calling asMap(): they will
cause
> a NullPointerException or an IllegalArgumentException.
> If this is the desired response is questionable.
>
>
> > - the implementation didn't correctly handle the values(), entrySet() or
> > keySet() methods which should provide a view onto the real data
> > (which would
> > actually be tricky to implement).
>
> Indeed, that would be way more complicated than the current
implementation.
> I think a little bit more effort would be reasonable. So, at least the
last
> point should be implemented for a correct behaviour.
> About the other I am not sure (especially at the first point I am not sure
> what the best way would be to handle it elegantly).
>
>
> -Moritz.
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
