Accidental enum extension [SOLVED] (but needs fix?)

Started by monkey0506, Wed 01/06/2005 03:46:59

Previous topic - Next topic

monkey0506

I have found something of a problem with AGS.  I defined a enum in my header file (just a note, this has nothing to do with the dialog module) named, "CursorMode" so that I could keep track of the current cursor mode just a little bit differently than AGS does it, as well as make use of it in functions and what-not.

Anyway, when I was typing "mouse.Mode = " I noticed that the auto-complete function was displaying MY CursorMode enum values as legal values for mouse.Mode (in addition to the eModeXXX ones).  In fact, it even compiles correctly.

*In case it has anything to do with it, the enum did declare my cursor name enumerations with the same numerical value as the cursor number.*

My initial thought was that perhaps because my variable was defined as "CursorMode Mode" it was encountering some kind of ambiguity between Mode and mouse.Mode.

Changing Mode to MyMode had no effect however.  Then it occurred to me that perhaps it had to do with the enumeration name.

Changing CursorMode to MyCursorMode did change it.  It made it so only the mouse.Mode values were displayed, and not mine.

Well...That's fun.  ***BTW in case you're wondering as to the name, I titled it that because the mouse.Mode enum seems to have inherited my enum values...***  Nevermind that last bit... I changed the name.


monkey0506

Something else, I have this enum in my script header:

enum CursorMode {
  eWalkTo = 0,
  eLookAt = 1,
  eUse = 2,
  eTalkTo = 3,
  eGiveInventory = 4,
  eUseInventory = 4,
  ePickUp = 5,
  eGive = 8,
  eOpen = 9,
  eClose = 10,
  ePush = 11,
  ePull = 12
  };

And this enum in the global script (for testing purposes):

enum CursorMode {
  eCurModeExtension1,
  eCurModeExtension2,
  eCurModeExtension3
  };

Problems:

1.  It compiles (even though the enumeration has already been declared).
2.  The eCurModeExtensionX variables are not autocompleted (because the extensions are not global), but are legal values.
3.  Trying to further extend the enumeration (from within the global script) creates an error stating that the enumeration already exists.

If this kind of enum(eration) extension is a feature, I can understand that (and possibly make use of it), however, I don't think that the user should be able to extend the built in enum types (as I appear to have done with CursorMode).

In fact, I just looked it up in the manual, and that is exactly what has happened:

Quoteenum CursorMode {
  eModeXXXX,
  eModeXXXX,
  ...
};

The CursorMode enumeration is generated automatically based on your mouse cursors. The cursor mode name is taken, all its spaces are removed, and eMode is added to the front.

I have extended this enumeration (accidentally).  Personally I don't think the built-in enumeration types should be extendable (if it's preventable without losing enum extension all together).

In any case, I'll just change the enum name now that I know it's built-in.

Scorpiorus

Hmm, I too noticed that if a enum type is defined outside the main script (i.e. in the header or it is automatically generated like with CursorMode) it is still possible to define another one with the same name in the main script.
The same happens with variables -- if I declare a variable via the script header I can then declare a enum type in the main global script that uses a name of that variable.

It is also possible to have reserved words in naming of enum, i.e.:

enum if {
...
};

enum int {
...
};

etc...

monkey0506

Wow. :o What have we done?  We've created a monster!

Pumaman

Eeek yes, the compiler allows enums to be redefined. I'll get it fixed, thanks for letting me know.

In the meantime, don't do it :P

monkey0506

Aw, come on Chris, you're no fun! :D

But I think it would be useful if you could extend an enumeration.  I can't think of a particular example at the moment, but it could come in handy.  While you're messing with it... :D

SMF spam blocked by CleanTalk