Java generic trouble

General Discussions
#1

I’ve been writing a graphics engine for a while now and I keep running into trouble when I try to abstract state handling. Given the engine I’ve written, I can completely implement applyState(State previous) in the State super class (it then uses custom peers to actually apply it). What I want to do is say (using Light as an example) applyState(Light previous), but have everything still coded in State.

One solution I came up with was to have State be declared as

public class State<S extends State<S>>

and then applyState becomes applyState(S previous).
Using Light as an example again, Light would be declared as

public class Light extends State<Light>

However, this solution seems very fragile and clumsy to me. Is there a better way of solving this kind of problem?
Let me know if I need to explain more,
Thanks

#2 
public static class Light extends State

Is all you want, from what I understand. I don’t think you want to deal with generics at all in the class declaration.

#3

In a simple situation, yes that’s what I would want. However, my situation is more complicated and I will only resort to that if I can’t think of another way of doing things. I will give another example that hopefully shows my intentions better:

State is an abstract class that delegates to a StatePeer that handles state application. There should be a StatePeer for each type of state. So StatePeer would be an interface like:

public interface StatePeer<S extends State> {
     void applyState(S next, S prev, Context c);
}

and State would have a method like:

public abstract StatePeer<X> getStatePeer();

so in Light, it would come out as:

public StatePeer<Light> getStatePeer() {
     return new LightPeer(); // which implements StatePeer<Light>
}

Is this possible any other way than what I explained in my first post.

#4

I rescind my desires to stick with generics, I tried using them more and it just made things ugly and bloated. I’m just going to remove generics where necessary, and if someone tries to apply a Fog onto a Light unit, well they probably shouldn’t be programming.

#5

Yeah, a lot of good programmers will insist that Java generics are stupid and slow. I typically only use them when I’m dealing with Java’s built-in library, rather than creating my own. Instead, I try to design my structures differently.

#6

Generics slow, how is this possible with type erasure? ???

Light extends State, already smells is light really a state or does it simply have a state?

Why is this topic in general?

You need to elaborate more on what it is suppose to do I can only make (wild) guesses now.

#7

I originally put it in general because I thought the problem I was having could be present in general applications, even though my example is related to graphics. If it needs moving, that is fine with me.

Also, I’ve already removed the majority of generics from my code and it has made it much cleaner, so the problem I was having no longer exists (except for curiosity’s sake). Unfortunately I can’t seem to describe it any better, what is that you want elaborated?

#8

I have difficulty creating a picture of how the components are suppose to collaborate and what there purpose is.

One thing that was/is particularly interesting to me was how your first ‘solution’ was so similar to the signature of Enum.

#9

Generics definitely have their uses and I’m not sure where the notion that they are slow comes from - slower than what?

However I don’t think generics is the solution to your problem, what’s wrong with the following?

class State {
State( State prev, StatePeer next ) {… }
StatePeer getPeer() { … }
}

interface StatePeer {
void apply();
}

class Light implements StatePeer {
…
}

This is similar to the approach I use for state management.

Actually my engine maintains the ‘stack’ of each type of state in a rendering context rather than having each State point to the previous one.

I noticed you had a Context parameter in your code, if it’s a custom class could you not do the same using that?

#10

I guess this is getting off topic, but yes, the context keeps track of the previously applied state (the way I render everything, I don’t need a stack), so if a programmer lets the engine manage the state application I won’t run into trouble. I was interested in how to code the interface so that the method arguments enforced the requirement that a previously applied state is of the same type as the current state.

I’ve already moved away from generics for this state management (it now looks similar to what you recommended), and it cleaned up my code, so thanks for the help.