# XEN-F001: Enums **URL:** \ **Category:** XOD Ideas & Discussions\ **Created:** [October 10, 2018, 12:52pm UTC](https://forum.xod.io/t/xen-f001-enums/1208 "2018-10-10T12:52:04Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![gweimer](https://avatars.discourse-cdn.com/v4/letter/g/a9adbd/32.png) [@gweimer](https://forum.xod.io/u/gweimer)\ **Post date:** [October 10, 2018, 5:14pm UTC](https://forum.xod.io/t/xen-f001-enums/1208/2 "2018-10-10T17:14:07Z")
The only issue I see with this is name collisions if you will pull in values from other libraries. For example, the accelerometer library will pull in sensitivity values from an unrelated light-detector library (or another accelerometer library that uses different ranges). More explicit types (like accel-sensitivity) would help, but not eliminate the problem. Worst-case scenario: an input pin that accepts any value of data-type suddenly becomes an enum because another library used the same data-type name for an enum (not looking for enums in other libraries if none exist in current library would eliminate this issue – and save search time). You might also require flag to indicate that a node is to be used as an enum value (so random nodes don’t get pulled in); enum-2g name instead of just 2g would be one option (“enum-” could be stripped when displayed in drop-down for selection). One way to eliminate namespace collision would be to provide a method of specifying which library the enum node should apply to. Node names are one option like 4g@nkrkv/accel or 4g(nkrkv/accel); no library implies it is only for the current library (or allow “.” to indicate current library). “@” in node name could be the indicator that it is an enum node. A way to specify multiple libraries where it can be used would be a bonus, but probably much harder to implement. --- _[View the full topic](https://forum.xod.io/t/xen-f001-enums/1208)._