Suggestion: Remove sentinel values in enums

[Kakuri]

The problem occurs for me when I use an eRealm value as a dictionary key.

I can set the value using Add( eRealm.Hibernia, value ) but when I later try and retrieve the value, it isn't there. Adding some further debugging code I discovered that the value was accessible when using eRealm._Last as the key, but not eRealm.Hibernia.

[Graveen]

My post seems to show at equal value, the alphabetical order is used to retrieve them.

Try simply refactoring eRealm._Last in eRealm.Last. Does it work ?

[alex_speed]

Seems that you should avoid using enums in Dictonaries unless you want to write a bit of code
http://ayende.com/Blog/archive/2009/02/ ... zzler.aspx

[Kakuri]

Wow, thanks for that info!

Ugh... the real joy of learning languages is learning all their pitfalls and oddities!

It seems like such a nice approach to me to be able to do:

Code: Select all

int GetValue( eRealm realm, eObjectType type, eInventorySlot slot )
{
return m_valueDictionary[realm][type][slot];
}

(m_valueDictionary is a Dictionary<eRealm, Dictionary<eObjectType, Dictionary<eInventorySlot, int>>>)

This approach seems very clear and concise to me, but has been so problematic! Since enums make bad keys (and sentinel values in enums cause problems), anyone know of a similarly nice approach?

[Graveen]

cast the enum ?

[Kakuri]

It's ugly, and a bit of a pain as the tables are fairly large, but I haven't yet thought of a better approach.

[Kakuri]

I feel like we're still kind of in limbo with sentinel values... I would rather we didn't have them, and am willing to remove them (and fix as necessary), but we need to have an agreed solution. So far the solutions are OK, but less than exciting, and perhaps the severity of the problem is too low to warrant any changes at this point?

[Graveen]

In your last example, what is the trouble with sentinel values ? i can understand the perfs are not ok with boxing/unboxing of enum in a dictionary, but this is not related with sentinel. I guess the sentinel values are used higher to enumerate the whole inventory.

For me the cast is not ugly here.In this case, i prefer using an enum - which is structuring the code - and add a cast to gain perfs (this is to compare to the non sense which consist casting (byte)3 to match an enum where eRealm.Hibernia should be used).

What are your conclusion to changing all sentinels values ?

I think to be put it in DoL core, it should simply allow to add enum values in the more natural way, this is a real benefits, not having to care about sentinels, ie:

Code: Select all

enum eRealm
{
hibernia,
midgard,
albion,
}

becomes

Code: Select all

enum eRealm
{
hibernia,
midgard,
albion,
none,
}

(i prefer not assign corresponding values in enum, and when read from database, affect via switch or if statement: if (dolcharacter.realm==3) player.realm = eRealm.Hibernia; )

Having more methods is not a problem, w/e the solution you can meet.

Using IsDefined(), explose big enums to little ones, and make methods to target more little enums (ie globalinventory, carryedinventory, chestinventory,... the needed are all in the code, which is exhaustive on this point) can help

Yes, this is not prioritary dev, but leading to a simple and better structure is interesting, and if you are interested to do and if it matchs the above criterias, it sounds like an interesting improvment