otrunk now supports enum properties
Scott Cytacki
constants, and then use that as the type of a property on an OTClass.
They currently don't work in resource lists or maps.
If you want to transition something that used to use "public static
final int", it should be possible. You should be able to arrange things
so otml files that have integer values for these constants can still be
loaded. You just have to make sure the new constants you create have
ordinals that match your old constants. By default an enum constant is
saved by its name. But if the otml file has an int where the name
should be then that is handled and preserved when the otml is saved again.
If anyone has been using Strings to define constants it should be
possible to transition these too. There might be an issue with
capitalization but we can probably work around it.
There are a few benefits to this approach:
- generic editors: they can display properties of this type as a choice
instead of a blank field.
- schemas: they can now include these constants
- otml readability: places where integers where used can now be replaced
with more descriptive strings (an example is the sensorType property)
- speed: if you were using strings for something like this enums should
be faster at runtime.
- can use switch statement: if you were using strings for this you
couldn't use a switch statement, but with an enum you can
- type safety: by using an enum the compiler (eclipse) will know when
you've done something wrong.
- future documentation: if we get around to adding the documentation
annotations we've talked about then the various choices can be be more
easily documented in this approach.
I have transitioned anything to use enums, but there are tests that pass
which use them.
Scott