Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Type-safe containsKey get, et al #28

Open
io7m opened this issue Nov 5, 2015 · 2 comments
Open

Type-safe containsKey get, et al #28

io7m opened this issue Nov 5, 2015 · 2 comments

Comments

@io7m
Copy link

io7m commented Nov 5, 2015

Hello.

The standard JDK Map<K, V> interfaces contain methods such as containsKey that take an Object instead of a K, throwing away type-safety. I believe this is now considered to be a serious historical mistake and dangerous to the point that some IDEs have added specific checks to warn users when they might be using keys that aren't subtypes of K. I'm wondering if there are any plans to add additional type-safe replacement methods to the MutableMap and ImmutableMap interfaces specified in the GS API? Something along the lines of:

Optional<V> retrieve(K k)
boolean hasKey(K k);

... or:

@Nullable V retrieve(K k)

... if a dependency on Java 8 isn't allowed.

As far as I can tell, the implementations would be trivial and non-intrusive, and would obviously just be defined in terms of the existing unsafe methods.

@goldmansachs
Copy link
Collaborator

We currently don't have overloads of containsKey and get but could add them. We have a similar overload of the remove method MutableMapIterable.removeKey(K k): V.

We would probably use the name getKey for the overload of get. We would need to come up with a name for the overload of containsKey, or use your suggestion of hasKey.

@io7m
Copy link
Author

io7m commented Nov 5, 2015

I might suggest getValue for the get override, because you're obviously retrieving a value and not a key as getKey would suggest. I've no real preference for any of the names, just getting back type-safety will be enough.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant