What is the advantage of 'V remove(Object key)' ?

[Red Orchid]

The following code is a part of java.util.Map<K,V> :

<code_#1>
V put(K key, V value);
V get(Object key);
V remove(Object key);
boolean containsKey(Object key);
</code_#1>


The above code allows this:
--
HashMap<K, V> map = ....;
V val = ....;
....
map.remove(val); // # 2
--

#2 seems useless and prone to bugs.


What is the advantage of 'code_#1 over the following code?

<code>
V get(K key);
V remove(K key);
boolean containsKey(K key);
</code>

Thanks.

 

[Daniel Dyer]

The following code is a part of java.util.Map<K,V> :

<code_#1>
V put(K key, V value);
V get(Object key);
V remove(Object key);
boolean containsKey(Object key);
</code_#1>


The above code allows this:
--
HashMap<K, V> map = ....;
V val = ....;
...
map.remove(val); // # 2
--

#2 seems useless and prone to bugs.


What is the advantage of 'code_#1 over the following code?

<code>
V get(K key);
V remove(K key);
boolean containsKey(K key);
</code>

Do you mean why are the parameters of type Object rather than the generic
type? It's for backwards compatibility. If the Map interface were to be
changed, all existing implementations of it would also have to be changed.

Dan.

 

[Daniel Dyer]

Do you mean why are the parameters of type Object rather than the
generic type? It's for backwards compatibility. If the Map interface
were to be changed, all existing implementations of it would also have
to be changed.

That's not quite right, I should have said the code that uses those
existing implementations might have to change. More specifically, the
existing implementations allow you to attempt to remove an object of the
wrong type, so the new versions have to allow this as well. This is in
case any code that uses the Map interface relies on this behaviour. You
could argue that using remove or containsKey like this is wrong, but there
may be code that does this and Sun does not like to break existing code
unless they really have to (such as introducing new keywords).

Dan.

 

[Thomas Hawtin]

V remove(Object key);

What is the advantage of 'code_#1 over the following code?

V remove(K key);

How often is this question asked?

It appears to be down to wildcards. If the latter form was used, you
wouldn't be able to write code like:

public static void remove(Collection<? extends Dog> dogs, Dog dog) {
dogs.remove(dog);
}

Tom Hawtin

 

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thomas Hawtin schreef:

How often is this question asked?

It appears to be down to wildcards. If the latter form was used, you
wouldn't be able to write code like:

public static void remove(Collection<? extends Dog> dogs, Dog dog) {
dogs.remove(dog);
}

Isn’t the answer simply backwards compatibility?

H.
- --
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFFM0/ae+7xMGD3itQRAkR/AJ4qwMBz/OFhnT0LkCZ/yaEnQxNvPwCeOpRA
pMPqIMARf8svGQEB4nNNLds=
=mN2o
-----END PGP SIGNATURE-----

 

[Thomas Hawtin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thomas Hawtin schreef:

Isn’t the answer simply backwards compatibility?

I have seen that argument (including by Brain Goetz). However it doesn't
make much sense to me.

There was not a binary or source compatibility problem with defining
remove with a parameterised parameter type. As above, there are some
perfectly valid techniques that would have been made illegal. There is
nothing wrong with such techniques from a generic perspective, so to ban
them would seem odd to me.

Tom Hawtin