This has always been broken, but I was waiting to see how it was addressed in ActiveRecord::Enum before fixing to make sure I had something that was more future-proof. The fix does not work in Rails 3.2 or 4.0, so it is disabled in ActiveRecord <= 4.0 which seems like a good compromise. Previously when using dirty attribute methods, it was hard to predict whether you'd get the string value or the enum class instance. Now it will always return the enum class instance for any of the attribute change methods.
This reverts commit 9db4172. Conflicts: lib/classy_enum/base.rb After thinking about this for a bit and looking at some of the recent surveys on Ruby usage, it seems like a lot of people are still using 1.9.3. Since there's not a huge benefit to dropping support for 1.9.3, it will stay for now.
This was also used originally to support Formtastic and is no longer needed.
This was originally added as a way to expose a JSON version of the enum instance, but it doesn't really give you anything. If you want to serialize the enum instances, you can simply override as_json in the enum classes.
The null object was originally added to retain backwards compatibility with existing Formtastic support. It was a pain to maintain support for Formtastic, so support was removed, but the null object remained. The null object breaks expected behavior if you're expecting the value to be nil since it does not evaluate to a falsy value. Previously, blank values had the same methods as enums: alarm = Alarm.new(priority: nil) alarm.priority.nil? # => true alarm.priority.low? # => false Now, the value will be nil: alarm = Alarm.new(priority: nil) alarm.priority.nil? # => true alarm.priority.low? # NoMethodError: undefined method `low?' for nil:NilClass alarm.priority && alarm.priority.low? # => nil
The class_name argument was added to bring the API closer to how you declare class name's with other Rails functionality. To try and prevent confusion, the other 'enum' argument which did the same thing, has been removed from the documentation, but is still valid.
From my experience, it's rare to have more than a few models use ClassyEnum in a project. By requiring all models to explicitly include (or extend) ClassyEnum::ActiveRecord, it keeps other models clean and makes it more obvious where classy_enum_attr is coming from.