Enum dereferencing?

S1mon

I've been working on configuring some standard part color choices using a custom featurescript. As some of these options have been changing, I'm starting to wonder if it would make sense to have an internal code for the enum which is some random numbers/letters, and have all the human readable stuff in the enum const definition. That way parts which use the custom feature could continue to update without needing to redo configs if the color name changes slightly or if I add or move a color choice.

What I have is conceptually like this code snippet:

--------------------------------
export enum MyColorNames
{
  annotation { "Name" : "01 Red"
  RED,
  annotation { "Name" : "02 Blue"
  BLUE,
  annotation { "Name" : "03 Green"
  GREEN,  
}

export const MyColors = {
  "RED" : { "variant" : "-01", "color" : color(1, 0, 0), "colorName" : "Red" },
  "GREEN" : { "variant" : "-02", "color" : color(0, 1, 0), "colorName" : "Green" },
  "BLUE" : { "variant" : "-03", "color" : color(0, 0, 1), "colorName" : "Blue" },
}; 
--------------------------------


I'm considering doing something like this with random-ish codes:
--------------------------------
export enum MyColorNames
{
  annotation { "Name" : "01 Red"
  A12,
  annotation { "Name" : "02 Blue"
  B34,
  annotation { "Name" : "03 Green"
  C73,  
}

export const MyColors = {
  "A12" : { "variant" : "-01", "color" : color(1, 0, 0), "colorName" : "Red" },
  "B34" : { "variant" : "-02", "color" : color(0, 1, 0), "colorName" : "Green" },
  "C73" : { "variant" : "-03", "color" : color(0, 0, 1), "colorName" : "Blue" },
}; 
--------------------------------

The idea being that I could tweak the variant number, the color values, the names, or add/insert/delete color choices without screwing up part configurations which use this feature script too much. Right now, if I change the enums in the MyColorNames, then any config which uses that choice is undefined or defaults to the first choice.

Is this sort of dereferencing used much with enums?

EvanReese

Do you mean in case you start with "MyColorNames.A12" as "Red" and later want it to be "Orange" you don't want the internal name to be "MyColorNames.RED" still? That could work. The find/replace tool in the IDE is pretty good too, so it's not that hard to swap the name to orange, unless it's used across several Feature Studios.

S1mon

@Evan_Reese
Yes. That's one of the issues, but the main thing I'm trying to avoid is having parts (which use the custom feature) and assemblies which have been configured loosing their configurations because the enum is gone. The whole point is to have one document (the custom feature) to tweak the colors, names and codes.

Unfortunately I still have to enter or copy/paste the names of the configs, but overall this is saving some time and avoiding having slightly different colors or mismatched variant codes.

I'm assuming that there are other examples where configurations are being used to drive custom features and you might want to tweak the nomenclature for stylistic reasons or update something without having to fix a bunch of parts.