http://qs321.pair.com?node_id=902284


in reply to Moose: What about "class" attributes?

Moose has no base support for class attributes, and never will, mostly because I think they are a bad idea. That is not to say that I don't like static class data, I think that is fine and can easily be handled by using package level variables and "static" methods. But the idea of inheritable class attributes just make me cringe, but fortunately for those who disagree with me, Dave Rolsky has written MooseX::ClassAttribute which does an excellent job at providing this type of functionality.

-stvn

Replies are listed 'Best First'.
Re^2: Moose: What about "class" attributes?
by John M. Dlugosz (Monsignor) on May 01, 2011 at 10:06 UTC
    But the idea of inheritable class attributes just make me cringe
    So why does MooseX::Traits (which has your name on it) use hacks to achieve exactly that effect? The configuration of trait_namespace will inherit. If you don't like that, why not just use a simple package variable in the package of the object's original created type?

    I suppose someone else maintained it and added that bit... but how would you (or how did you originally) do it, in keeping with your stated design philosophy?

      So why does MooseX::Traits (which has your name on it) use hacks to achieve exactly that effect?

      This is the fun part about Open Source, just cause my name is on it doesn't mean I have done anything other then contribute some part of it and I am no way responsible for the contents ;)

      The configuration of trait_namespace will inherit. If you don't like that, why not just use a simple package variable in the package of the object's original created type?

      Well, in this case, inheritability is nice, but the goal here is more configurability of subclasses without altering the core MooseX::Traits itself (which would have global effects, which are bad bad bad).

      I suppose someone else maintained it and added that bit... but how would you (or how did you originally) do it, in keeping with your stated design philosophy?

      I am pretty sure jrockway wrote that part, it is not how I would approach it but this solution is not all that bad (I have seen worse). Keep in mind too that was also written quite a while ago, today one would accomplish this type of thing by making MooseX::Traits into a parameterized role using MooseX::Role::Parameterized.

      -stvn
        Ah, so instead of
        with 'MooseX::Traits'; has '+_trait_namespace' => ( default => 'Another' );
        you would write
        with 'MooseX::Traits' => { 'trait_namespace' => 'Another' };
        That could store the string in lexical variable that the instantiated role's code blocks are closed over, so it knows the value you told it. ((I'm borrowing the terminology from C++ templates: instantiate means to spit out a real type from a template))

        That certainly is more to think about.