declaring an enum based on an int?

[Allen Williams]

I have a simple enumerated type:

package dbMgr;
 
enum reqtype
    {
    unknown(0), topmsg(1), trbmsg(2), reqmsg(3),
    usrjn(4), chfjn(5);
 
    reqtype(int val){type=val;}
    int type(){return type;}
    private int type;
    }

There is an object that uses this type:

public class request extends Object
    {
    public request(int Key, Date Ts, reqtype Type, reqstatus st,
                   int Trkey, int Thrd, int From, int To, String Msg)
        {
        init(Key, Ts, Type, st, Trkey, Thrd, From, To, Msg);
        }
 
    private int key;
    private Date ts;
    private reqtype type;
    private reqstatus status;
    private int trkey;
    private int thread;
    private int from;
    private int to;
    private String msg;
    }

I read these values out of a database, where the reqtype (and reqstatus) are integers.

Hence, the variable "type" given reqtype, above. So, here, conceptually, is what I'm trying to do (in fact I tried this literally and it doesn't work). Note what I'm trying to use as the constructor in the request constructor:

    private request dbResultSet2Request(ResultSet rs)
        {
        request r= null;
        try
            {
            r= new request(rs.getInt("ReqKey"), rs.getDate("CreateTime"),
                           reqtype(rs.getInt("ReqType")), reqstatus(rs.getInt("Status")),
                           rs.getInt("TrKey"), rs.getInt("Thread"), rs.getInt("Sender"),
                           rs.getInt("Receiver"), rs.getString("Message"));
            }

How does one do this, short of using a switch statement?

TIA

[Ernest Friedman-Hill]

You can give your enum class a static method which, given a type, returns a value of that type. Have the constructor add each enum value, as it's constructed, to a map; then have this static just look up the object in the map.

[Jean-Francois Briere]

For each enum type you create a static valueOf(int) method:

enum reqtype
{
    ...
    
    static reqtype valueOf(int type) {
    for (reqtype rt : values()) {
        if (rt.type() == type)
            return rt;
    }
    return null;
    }
}

Then it's simple to use:

    private request dbResultSet2Request(ResultSet rs)
    {
        request r = null;
        try
        {
            r = new request(rs.getInt("ReqKey"), rs.getDate("CreateTime"),
                reqtype.valueOf((rs.getInt("ReqType"))), reqstatus.valueOf((rs.getInt("Status"))),
                rs.getInt("TrKey"), rs.getInt("Thread"), rs.getInt("Sender"),
                rs.getInt("Receiver"), rs.getString("Message"));
        }
        ...

Regards

[Jean-Francois Briere]

Have the constructor add each enum value, as it's constructed, to a map;

The map idea is good although I guess you meant static map.
Also be aware that (from the JLS):
"It is a compile-time error to reference a non-constant (�15.28) static field of an enum type from its constructors..."
The workaround is to use instead a static method in the enum ctor.

enum reqtype
{
    private static final HashMap<Integer, reqtype> map = new HashMap<Integer, reqtype>();
    
    ...
    
    reqtype(int val) {
        type = val;
        put(val, this);
    }
    
    private static void put(int val, reqtype rt) {
        map.put(val, rt);
    }
    
    static reqtype valueOf(int type) {
    return map.get(type);
    }
}

Regards

[Allen Williams]

I thank you genelemen. I see what you both have done. I think the map solution is better suited to larger enums, while, for what I'm doing, less than 10 or so values, the loop (which is basically a linear search vs. whatever the map uses [b-tree?]) is more appropriate. I think that's the fundamental difference. Agree?

One thing I didn't understand is what that quote from the spec about the "non-constant field" means.

[Jim Yingst]

There's really no need for either a map or a linear search here - an enum already has everything you need, built in. Every enum value automatically has an associated integer, called the ordinal. The first listed enum value has ordinal 0, the second is 1, etc. Conventiently, this is exactly the same set of values Allen is explicitly setting up with the constructor and the "type" field. It's unnecessary, since this is built into all enum types. The reqtype code can be replaced with:

enum reqtype {
    unknown, topmsg, trbmsg, reqmsg, usrjn, chfjn;
 
    int type() { return ordinal(); }
 
    public static reqtype valueOf(int type) { return values()[type]; }
}

That's it. The type() and valueOf() methods are so simple that you may chose to omit them - callers could do the same thing just as easily. However it seems that the uses of the ordinal() and values() methods are not widely known among programmers yet, so including the methods explicitly here may help usability.

[Ernest Friedman-Hill]

I wrote my answer assuming the integer values could be different from the ordinal value, since he was using a member to store it. But an equally valid assumption is that he just didn't know about this machinery.

As far as the "static map" explanation.... umm, yeah.

[Jim Yingst]

Yeah, my answer assumes that the legal type values used in the DB will be 0, 1, 2, 3, etc. If that's the case, great. If not, yes it would be preferable/necessary to have a separate field in the code, as originally shown, agreed.

Also, I'd just use a HashMap like EFH suggested, as it's simplest to code and scales well. If by some chance there's really a need to optimize the lookup for better performance (highly unlikely since the database access will almost always be much slower than the HashMap lookup) - well I suppose I'd just code up a switch statement or array lookup, as either wil most likely be faster than either linear search or HashMap lookup under most circumstances. Such things aren't usually worth worrying about until you have a demonstrable case where a method is creating a performance problem.
[ September 23, 2006: Message edited by: Jim Yingst ]

[Allen Williams]

Yep, got it, and I really appreciate the information. I was aware of the ordinal facility, and, although it is set up that way now, didn't want to preclude negative values for anomalous events, etc. In fact, I wrote it a couple of days ago and only just yesterday added the unknown(0), which is what made it map so exactly to the ordinal function.

Thanks!!

Now, to post my next question;0)