Ah, I see. The ability to access a member variable of the returned value 
without casting or storing it in a local variable doesn't seem like a 
particularly strong use case though. And this code isn't especially pretty 
either:

tableView.getSelectedRow(Foo.class).bar();

I think I'd have to look at the TableView API to understand what that code is 
doing, whereas this, while a bit cumbersome, is readily understandable:

((Foo)tableView.getSelectedRow()).bar()

G

On Jun 22, 2010, at 8:49 PM, Alejandro Vilar wrote:

> 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.
>  

Reply via email to