Re^2: Informal Poll: why aren't you using traits?

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!

Comment on Re^2: Informal Poll: why aren't you using traits?

Replies are listed 'Best First'.

Re^3: Informal Poll: why aren't you using traits?
by stvn (Monsignor) on Nov 19, 2005 at 13:54 UTC

The other option is to use Multiple Inheritance (which is what Catalyst uses).

It is important to note thet Catalyst uses MI, but it also uses NEXT. Using NEXT allows a greater control over MI and how and when methods are called.

But to be honest, MI doesn't have to be so scary/ugly/problematic anymore. DBIx::Class (which is associated with Catalyst) is actually in the process of transitioning from MI with NEXT to using Class::C3. Class::C3 is a module I wrote recently which imposes a sane ordering for method dispatch under multiple inheritence. It comes originally from the language Dylan, and has some roots in early LISP object systems (pre-CLOS), and has most recently been adopted by Python. There is more information on C3 in the SEE ALSO section of the Class::C3 POD docs.

-stvn

[reply]


Do you know where your variables are?
	PerlMonks