How can an enumeration type have a space in it? (Request for fix)

#1 No because they're just strings and TorqueScript has no native enumerators. This is just an internal field string value to numerical value translation hook.

#2 Well. The problem comes when you are converting this mess to CSharp. If it is "TS enumeration" it should act like an enumeration. Atleast in my humble opinion

#3 I mean it does say "ImplementEnumType" which one would think... well an enumeration.

#4 "That's what you get for thinking!"

And

"I'll do the thin'in' 'round here!"

I do agree, though - Just because you can do something doesn't mean you should. Did you drop this in the git issue list?

Although, you should be able to create a C# construct that converts between the TorqueScript enum and something more palatable with a little bit of elbow grease and ingenuity....

#5 You might have to bite the bullet and allow for spaces and convert them. The reason is you never know what someone will do with their own code. Even if it gets fixed in T3D it may end up being a bug report by one of your users that it will not work with enumerators that have spaces. Or you could just tell users that spaces are lame and they will be converted to underlines with prejudice. ;)

It might be messy, it might be lame, but that's the compatibility game.

Edit:
Also, did you watch out for case? Everything in TS is caseless.

#6 To clarify the purpose of the ImplementEnumType is only meant specifically for editor interaction when the user needs to manipulate a field that is using it. In the early Torque Game Engine (TGE) days we had fields like this that only accepted manually entering a value from 0 to whatever the max range was to change a mode. Now with T3D the user gets a dropdown list of options that the field can be set to associate with a specific mode or state. That is the only reason why this exists.

So again there are no enumerators in TorqueScript and all that ImplementEnumType does is take a string received from TS side when its binded object field is changed and translate it to the associated value to be stored within the C++ engine side for said object's field value. Vince, I'm not sure why you would even want to expose the faked enumerators to your CSharp implementation since that just makes more work for you and if additional enumerators were added then you'll have to update it again. I suggest just keeping said fields as strings but with a special flag or binding to know that they need to be passed to those ImplementEnumType hooks.

A bit off-topic but I find that TSMeshType to be misleading since it should have been called TSCollisionType since that's exactly what it relates to.

#7 @Nathan - you do remember that they're making a collaborative level editing tool, right? :)

Mainly for the reasons Demolishun states I can't really argue for changing it, though. Because the engine will allow it someone else will do it even if it's "fixed" in the engine. Might as well find a way to cope with it.

#8 @Richard: I understand that, but what is wrong with interacting with the ImplementEnumType object fields exactly like the current editors do already? This will avoid the need to even care about ImplementEnumType and its faked enumerators with spaces in the names as the field value should be handled as just your typical string values, but presented as dropdown (or referred to a choice) list of options, again as done in the current editor.

#9 It's extra work on the C# side. And it's ugly. Other than that, nothing is patently "wrong" with it. For people accustomed to working in most programming languages it comes as a surprise that this even works because almost no one else does anything like it (I can't think of any off the top of my head).

So - as I said in my last post - for the reasons Demolishun (and then you) stated it's better in the long run to leave it alone.

That said, what's wrong with devising a better, cleaner and more intuitive way to handle this?

This just goes on the long list of things that are less than elegantly executed in Torque <shrug>.

#10 I'm just saying that there is some "Constants" about programming. Variable names can't start with numbers, they can't have spaces or special characters, etc. Enums have standard rules as well,

The moment you start to deviate from what the "Standard" expected behavior or syntax is you start down a slippery slope which never ends well. There is reasons for these "Standards".

Vince

#11 I think Nathan hit on exactly why this exists. Instead of thinking of this as an enum, think of it as a list of strings that map to some value. And the intent of that list of strings is to be displayed in a dropdown control for the user to pick from.

Perhaps the issue is that the helper #define is called ImplementEnumType instead of something like StringValueMap.

- Dave

#12 Yeah, but the funny thing is, the engine replaces the spaces with underscores farther in. So... um, couldn't we make TorqueScript run faster by not having to do the replacement and just put them in w/ underscores upfront?

#13 @Vince:
Where is this underscore replacement happening in the engine? If I put a breakpoint on line 179 of console/dynamicTypes.h then I can see that the enum table's mName member contains strings with spaces. So in this code:

virtual const char* getData(void *dptr, const EnumTable *tbl, BitSet32 flag)
{
   S32 dptrVal = *( S32* ) dptr;
   if( !tbl ) tbl = getEnumTable();
   const U32 numEnums = tbl->getNumValues();
   for( U32 i = 0; i < numEnums; ++ i )
      if( dptrVal == ( *tbl )[ i ].mInt )
         return ( *tbl )[ i ].mName;
   return "";
}

It returns the value "Collision Mesh" when the mInt value is 2 (just like the enum table in your original posting).

If you take a look at the setData() method just below, it is doing just a straight dStricmp() on the same mName member, without any mangling.

Is this adding and subtracting of underscores happening outside of this code?

Thanks!

- Dave

#14 I thought I saw it doing it in the editor.

#15 @Vince:
Don't get me wrong, though. If you guys can come up with a plan (and more importantly, a Pull Request) that can meet both the needs of the editor as well as your C# work, the T3D Steering Committee would love to see it.

Just because something was done one way in the past doesn't mean it must be done that way today. You'll just have to think outside of your immediate needs and plan on something that will work with T3D's existing editors. Unless you'd like to overhaul those too. ;)

- Dave

#16 Wouldn't the enum type be implemented like this (C++ version):

std::map<std::string,<TSStatic::enum,std::string>> enumMap;
enumMap["Collision Mesh"] = data; // ?, probably needs a struct or something, but you get the point