First, let me apologize in advance. I slept wrong, and I'm frustrated. Rant ahead.
I will start this rant by pointing to this RT bug and telling a story. I'm upgrading Catalyst helper code in Handel. It currently uses Data::FormValidator, but I decided to try out FormValidator::Simple instead because I liked it's error message handling more.
Long story longer, it wouldn't display the correct messages when those message were set on an FVS object, but it did when the messages were set on the FVS class. Looking at the source, it's apparent that it makes use of Class::Data::Inheritable. While this particular problem can probably be fixed, I think it's a symptom of a larger issue.
I hereby call out a personal jihad against all modules that use Class::Data::Inheritable rather than something like Class::Data::Accessor or Class::Accessor::Grouped. (Disclaimer: I was involved in both modules).
Maybe DBIx::Class spoiled me, but IMHO any module that allows you to adjust its functionality through/for things like setting messages, or options, possibly using accessors, needs to do so at the Class level, AND at the object level. I want to change how one instance of FormValidator::Simple works, not [be forced into changing how] all instances of FormValidator::Simple work in the same process.
This is especially a problem when you're trying to create multiple virtual things (like seperate web stores in the same physical site) that may want to alter their configs per store.
So, just to review: Class Data only: Bad. Class Data + Object Data: Good.
Of course, I could be off my rocker, or R0X0R.
