Well you are right about class parameter vs direct casting, I have a better example to explain why I put that example:
1) public <T> T getSelectedRow(); Foo foo=tableView.getSelectedRow(); Foo foo=(Foo) tableView.getSelectedRow(); //<-- current foo.bar(); 2) public <T> T getSelectedRow(Class<T> requiredClass); tableView.getSelectedRow(Foo.class).bar(); ((Foo) tableView.getSelectedRow()).bar(); //<-- current, not so clean tableView.getSelectedRow().bar(); //<-- doesn't work Regards Alejandro From: Greg Brown [mailto:[email protected]] Sent: Martes, 22 de Junio de 2010 08:25 p.m. To: [email protected] Subject: Re: Question about generics in some classes Is there a particular reason why TableView doesn't support generics? public <T> T getSelectedRow(Class<T> requiredClass) { } It is certainly doable, but is this: Foo foo = tableView.getSelectedRow(Foo.class); significantly better than this: Foo foo = (Foo)tableView.getSelectedRow(); The other signature might be worth considering - need to give some thought to potential downsides. Also with query parameters, this is not a big deal, but including shortcut methods as follows can be helpful: putParameter(String key, int value); putParameter(String key, double value); putParameter(String key, boolean value); putParameter(String key, Object value); Seems reasonable. However, if we were to add these, I think it might be clearer to add them to QueryDictionary as put() overloads.
