• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Ho to not use casting on this generics?

 
Johan Zahri
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dear all,
I have the following code:



Does anyone knows a better way of the usage of generic to avoid using

I was thinking well since I know that XResult has a way to instantiate itself there is no way that the casting would not work., would it?
But it just doesn't feel good using casting, somehow.

Regards,
Johan

 
Johan Zahri
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
never mind I just did away without using generics..
i guess it's sufficient..

 
Winston Gutkowski
Bartender
Pie
Posts: 10422
63
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Johan Zahri wrote:Does anyone knows a better way of the usage of generic to avoid using

I was thinking well since I know that XResult has a way to instantiate itself there is no way that the casting would not work., would it?
But it just doesn't feel good using casting, somehow.

Well spotted. "Code smell" is a good sense to acquire, so don't ignore it.

And to answer your question: yes there is - make Result generic too.
In this case, it's as simple as:then whatever class extends Result uses the notation:which results in a getNewInstance() method that returns a Failure.

BTW, generic types, by convention, are usually a single upper-case letter, rather than things like 'XResult'. This is so you can distinguish them from regular class/interface names. The norm is to use 'T' (for 'Type') unless you have a good reason not to, but it's not required. For instance, an interface like Map<K, V> uses its notation to distinguish between 'Keys' and 'Values'.

HIH

Winston
 
Winston Gutkowski
Bartender
Pie
Posts: 10422
63
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Johan Zahri wrote:never mind I just did away without using generics..
i guess it's sufficient..

Looks fine to me. You don't always have to use generics .

Winston
 
Rob Spoor
Sheriff
Pie
Posts: 20546
57
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston Gutkowski wrote:The norm is to use 'T' (for 'Type') unless you have a good reason not to, but it's not required. For instance, an interface like Map<K, V> uses its notation to distinguish between 'Keys' and 'Values'.

Don't forget E for element types, like those of collections and iterables. But keep in mind that the name is always free to choose. For instance, I have one interface with I for the input type and O for the output type, because these make more sense than T and U, for instance. I therefore am more inclined to use either a simple T (for type), or the first letter of what the generic type represents (Key, Value, Element, Input, Output).
 
Winston Gutkowski
Bartender
Pie
Posts: 10422
63
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rob Spoor wrote:...or the first letter of what the generic type represents (Key, Value, Element, Input, Output).

Absolutely. I was just trying to say that 'T' is normal unless you can think of something better.

Winston
 
Johan Zahri
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks guys for all the input.

Just realized that what I was actually trying to do (quite a distance from the topic.. sigh)
turned out its already implemented in java.util.concurrent.RunnableFuture<Result> :P

As one wise man says..
"reuse!"

Cheers.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic