Inferring return value assignment types - ever seen this ?

Question

Consider a class designed to hold arbitrary values defined at runtime. It is backed by a Map<String,Object> and values are stored and retrieved by a String identifier. Basic type checking is also performed.
Setting the values is straightforward: obj.set(name, value) but I have two candidates for syntax of getters.
First an example of the obvious approach, where getInteger(&hellip;) performs type checking, casting and explicitly returns an Integer:
Integer id = obj.getInteger("id") ;This is ok but I discovered a more consice syntax that works without without explicitly naming a type nor sacrificing type safety any further:
Integer id = obj.get("id") ;In this approach we use a generic method, where the return type is inferred and passed to the method. Here's how I do it:
// root method that is called by both approaches
private <K> K _get(String name, Class<K> clz) {
  Object value = map.get(name) ;
  // check for null, assignability, etc.
  if (!clz.isAssignableFrom(value.getClass())) {
      throw new RuntimeException(clz + " is not assignable from " + value.getClass()) ;
  return (K) value ;
// method 1 - the obvious way
public Integer getInteger(String name) {
  return _get(name, Integer.class) ;
// method 2
public <T> T get(String name, T...ts) {
  if (ts.length > 0) throw new RuntimeException("Illegal usage...") ;
  return (T) _get(name, ts.getClass().getComponentType()) ;
}This works becaues type T is used for both the var-arg array and the return value. Of course, it probably fails if you provide additional args - you're not supposed to. ts.getClass().getComponentType() returns the type you are assigning the return value to.
Not many languages can take this into consideration. In a way, it makes the return type part of the signature.
Advantages:
- Much smaller API
- Dynamic extension for use with a new datatype doesn't require adding a new getX() method
- Members can be treated uniformly, such a through iteration
Disadvantages:
- Involve the confusing zero-length var-args in the api that must be ignored
- Type is inferred to be Object when the return value is not assigned
At first you might think that the method 1 is more type-safe but in fact it is not. Using method 1 you have to align the method with the assignment type, but you can still exception at runtime. In method2 the datatype is simply inferred.
I'm interested in your thoughts on this teqnique. Please let me know if you have a way of concealing the var-args oddness. I think this technique could complement various patterns quite well, such as factory.
Thanks for your input.
Edited by: crackleOK on Jul 21, 2009 4:46 AM

Answer 1

crackleOK wrote:
JoachimSauer wrote:
The only redeeming quality is that it can be very nice to use such code.API's are to use (and often have ugly guts). Unfortunately true, but not a good reason to write ugly implementation code. If you only care about code quality up to the API, then you only care about the shiny coating of your car as well and don't mind the rust as long as you don't see it.
As I said: sometimes the tradeoff is worth it, but it should still be weighted.
Also: the ignorable varargs parameters are not needed in any way whatsoever.Please explain.From what I see you can replace this method:
public <T> T get(String name, T...ts)
// with
public <T> T get(String name)without any loss of functionality.