The way I understand Traits is that they are really just mixins with lots of extra protections against method name collisions. And a mixin is really just a method that is imported into your class from another module or package.
I do a lot of work with CGI::Application, and we have an extremely basic plugin system that just works like a mixin. Your plugin exports some useful methods to the application class. I have never been quite happy with it, and I believe traits might be a better answer to this problem (I need to investigate that more thoroughly though).
To give you an example, we have a Session plugin that exports a 'session' method which when called just returns you an active session object. So CGI::Application doesn't know anything about sessions, but when you load the Session plugin (or trait in this case), you can now call $self->session and you get yourself a session object or a tied session hash (whichever you might prefer). So what Traits can provide is the mechanism for getting that 'session' method added to your class (that is my limited understanding of it anyway).
This might not be a problem that traits were written to solve, but I think it may fit in nicely with what we are doing. The other option is to use Multiple Inheritance (which is what Catalyst uses), but I have never like MI, especially once you get to adding 5 or 6 entries into your @ISA. Not that mixins are better than MI, they both have their problems. I can just accept the problems with mixins easier than I can the problems that MI has.
And perhaps Traits can solve most of the problems I currently have with mixins!
|