Using Enums instead of Constants in 2.0, an Idea!

archive development-discussion-jme2
1

Hi all,



I know the idea of using enums instead of constants has been mentioned for 2.0 and I was musing on the idea and have come up with something that might be useful for making jME more render implementation independant.



Basically we create enums for all the areas that need them (i.e. texture types) and inside each enum we have a method for getting the render specific code.



For example,



public enum TextureType {
    RGB("rgb", "glrgb", "dxrgb"),
    RGBA("rgba", "glrgba", "dxrgba");

    private String jmeCode, glCode, dxCode;

    private TextureType(String jmeCode, String glCode, String dxCode) {
       this.jmeCode = jmeCode;
       etc
    }

    public Object getJmeCode() {
        return jmeCode;
    }

    etc
}



Then the usage would be:


Renderer.doSomething(blah, blah, TextureType.RGB);



Inside a LWJGL implementation for example you'd have:


public void doSomething(Object a, Object b, TextureType tt) {
    GL11.doSomething(a, b, tt.getGLCode());
}



This would save some kind of horrible "if enum equals rgb then use code xyz" statement in each method that uses enums.  This would also be handy if for example, the one implementation required an int constant but another required a string (would require some autoboxing for primitives, hmm).

I'm not sure if this would work or not or even if we'd need a bunch more codes (i.e. GL11Code, GL20Code, GLARBCode, DX9Code, DX10Code etc etc) but I figured I'd mention it as it might not be an approach anyone has thought of yet.

Would also like to point out I've never used DX and I'm just assuming it doesn't use the same constants...


Thanks,
Chris
2

Renanse already switched from int constants to enums. And already the int constants were mapped to gl values. There is one problem with your idea: every display implementation would need to alter the core (the enums) - that'd be quite bad design.

3
irrisor said:

There is one problem with your idea: every display implementation would need to alter the core (the enums) - that'd be quite bad design.


I assume the constant values used are defined in the API specification so we'd basically only need them for GL and DX (in other words LWJGL and JOGL renders wouldn't need their own codes just the GL ones)?

I agree it's not really the best idea but at the time of writing I seemed to like it better than making whoever does a DX implementation convert all the enums every time, hmmm.

Just musing as I said!  :)
4

The Enum must be the same ever.



The enum value "interpreter" that must be renderer specific.

5

The work for switching to enums is already done too.  :slight_smile:

6
clovis said:

The Enum must be the same ever.

The enum value "interpreter" that must be renderer specific.


Enums in Java are basically classes, so to me it seems a little silly to have another class as an interpreter when the enum itself could hand out converted values.
7

But Enum cannot be inherited, so you can't implement and Enum for DX Renderer and another Enum for OGL renderer.

You must implement specific behaviour for the renderer chosen in some place other than the enum. If not, the engine would not be renderer independant.

If in the future, a OpenGL4 renderer would be supported (for example), you just have to implement the "interpreter" for the Enum value, not REIMPLEMENT the Enum.

8

I have to side with clovis. By pushing information into those Enums your explicitly tying implementation details into a place where it has no business being. And, by definition, since you can't extend or instantiate an Enum it really isn't possible to do anything but deal with the enum differently in your implementation depending on which one is in use.