Redesign SDLEnums to not be objects

[joeljfischer]

Lots of enum objects permanently in memory now, could do conversion between String Enum <–> Integer Enum instead. Less memory overhead, probably more CPU overhead, likely negligible. Removes an enormous amount of code.

Right now, Enums are designed as objects. From what I understand, there are a few reasons for this:

1. Namespacing. You can type SDLAmbientLightStatus and get a list of the component enums.
2. Typechecking. You can call the [valueOf:] method on an enum and get the object, or nil if it is not a component object.

See the comment below for more details.

Also, see #425, perhaps just typedef EnumName NSString and stringly typed constants?

[joeljfischer]

I have come up with a (completely untested) possible method of doing this. See the following gist for an example.

https://gist.github.com/joeljfischer/67bd1d4da444e948cb5d

There are still objects here, each SDLEnum object holds a single (enforced by a singleton pattern) dictionary held in it's overridden +[map] method. This maps a enum value to a string. The superclass SDLEnum contains class methods that are capable of converting between the two. Enum -> String is a simple dictionary lookup in 0(1) time. String -> Enum is 0(n) time worst case. These two cases could be reversed if desired with no impact to developer facing API.

To the developer, all they ever need to deal with are the public enum values. This will help with enforcing correct values and will be very fast, since they're just integers. At runtime, when we need to, we'll convert back and forth for the protocol.

[GENIVI]

hi, Joel

Thanks for your gist. I'll hold on them and try it tomorrow and keep you
updated.

Thanks
Yingang

[joeljfischer]

Hey Yingang, I would not recommend trying to implement the ideas presented in the gist into the library at this point. To actually do so would require a lot of work and changes to many places in the library. Many/all enums would need to be altered to work in the manner described, and lower level changes to message creation and parsing would need to be implemented. The gist was intended strictly as a presentation of ideas for discussion for now.

[joeljfischer]

Note that all NS_ENUMs could be moved to a separate public enum file, all +[map] methods could be moved into SDLEnum base class as separate methods, such as +[appHMITypeMap]. This would eliminate a crazy amount of classes, and allow the SDLEnum class to be private to the library, reducing public class exposure.

[joeljfischer]

Closed in favor of #425