XEN-F001: Enums

[nkrkv]

Thank you for the constructive feedback!

@awgrover

I would be strongly against having each enum value be a user-visible patch (think what it would do to “search”!).

I see your concern. If we have a choice of 30 we should define these 30 items somehow. And I’m looking for a way to make it possible without introducing as little new concepts and new UI as possible. We have patches, nodes, custom types, comments, pins,… The enums riddle should be made out of them somehow.

So, let’s imagine the Neopixel constants in the frame of the original concept. An author will have to create a custom type neopixel-type by creating a patch node which takes a raw value of XOD byte type and produces the “wrapped” value of type neopixel-type. Now he creates the enumeration items. A patch per item. The patch is a trivial wrapper around neopixel-type with the input pin hard-coded to the corresponding hex value.

rgb
rbg
grb
gbr
brg
bgr
wrgb
wrbg
wgrb
wgbr
wbrg
wbgr
rwgb
rwbg
rgwb
rgbw
rbwg
rbgw
gwrb
gwbr
grwb
grbw
gbwr
gbrw
bwrg
bwgr
brwg
brgw
bgwr
bgrw

Indeed, the search will bury any useful mentions of “RGB” behind the routine variants But if we’ll ignore the clutter for a moment, it should work fine. In particular, we’re leaving the way to “force” a forgotten enum value by using the raw neopixel-type node directly.

OK, how can we reduce the clutter without inventing something principally new? One idea which came to my mind is borrowing the naming scheme from generics specializations. So, the patches would be:

neopixel-type
neopixel-type(rgb)
neopixel-type(rbg)
neopixel-type(grb)
neopixel-type(gbr)
neopixel-type(brg)
neopixel-type(bgr)
neopixel-type(wrgb)
neopixel-type(wrbg)
neopixel-type(wgrb)
neopixel-type(wgbr)
neopixel-type(wbrg)
neopixel-type(wbgr)
neopixel-type(rwgb)
neopixel-type(rwbg)
neopixel-type(rgwb)
neopixel-type(rgbw)
neopixel-type(rbwg)
neopixel-type(rbgw)
neopixel-type(gwrb)
neopixel-type(gwbr)
neopixel-type(grwb)
neopixel-type(grbw)
neopixel-type(gbwr)
neopixel-type(gbrw)
neopixel-type(bwrg)
neopixel-type(bwgr)
neopixel-type(brwg)
neopixel-type(brgw)
neopixel-type(bgwr)
neopixel-type(bgrw)

Nodes with parens in the name are already (a) valid and (b) do not appear in search unless the query contains the left parenthesis character. XOD IDE might use the contents in parens to be used as a label in the drop-down list.

I’m sure you’re thinking about a way to encapsulate all items in a single patch completely, but I failed to find a straightforward user flow of doing it. What can you say about the solution above?

@awgrover

Which also suggests a more generic “list of choices” type in XOD. Otherwise behaving as you suggest, it’s output is a standard type (string, for example, or number). Perhaps naming some values is useful: “seizure induce” for .1 second period, “lowest perceptually continuous change” for 30 for pwm values, “leaded solder” for 320 (“lead free” for 600).

pulse frequencies

is a good example of this. I think it would not work to have rates be a custom-type: it is not uncommon to calculate rates. But, some named ones might be friendly.

Perhaps enums should auto-cast from the obvious type (typically number)?

I think we’re mixing the enumeration and constants concepts here? The 1-hz, seizure-induce, leaded-solder nodes might be single-output nodes which do not involve any new custom types. XOD IDE may pick up variant values for Inspector inputs like it does for enums. However, in such case, it will leave the field editable, that is allow entering arbitrary values.