Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Moose goodness for status-code values?

by sundialsvc4 (Abbot)
on Nov 18, 2011 at 18:09 UTC ( [id://938893]=perlquestion: print w/replies, xml ) Need Help??

sundialsvc4 has asked for the wisdom of the Perl Monks concerning the following question:

You know the drill ...

if ($record->{'status1'} eq 'F') { ... }

I know that Moose provides an “enum” type-constraint, but that’s not exactly what I want.   I want to be able to specify a map of codes to semantic meanings:

{
'F' => 'fail',
'P' => 'pass',
}

And I guess that in my ideal notion of this, I would be able to automagically create Boolean accessors ...

if ($record->fail) { $record->pass(1) }; # FLIP STATUS

Does it exist?

Replies are listed 'Best First'.
Re: Moose goodness for status-code values?
by stonecolddevin (Parson) on Nov 18, 2011 at 18:24 UTC

    Seems like this might be more like what you're looking for: Moose::Meta::Attribute::Native::Trait::Bool

    Three thousand years of beautiful tradition, from Moses to Sandy Koufax, you're god damn right I'm living in the fucking past

Re: Moose goodness for status-code values?
by zwon (Abbot) on Nov 19, 2011 at 08:38 UTC

    I thinks traits are a way to go. If you don't like Bool, you can define your own.

Re: Moose goodness for status-code values?
by sundialsvc4 (Abbot) on Nov 19, 2011 at 16:43 UTC

    I do think that Traits are likely to be the solution, and I was hoping that one already existed ... especially since I see a “MooseX::TypeMap” that looks very interesting indeed but that is not quite what I want.

    The motivation for my quest is that these status-codes are already present in a large database and already being used in the crufty code that my team is re-engineering.   There is, therefore, a lot of code that tests these values with eq, and we have already encountered several places in which that isolated logic is outright wrong.

    So, obviously, I want to consolidate into one Moose-goodness place:  

    • The value of status can be A, B, C, or D; never anything else.
    • The meaning of status='B' is (whatever).
    • If you want to assert that “such-and-such is now The Truth,” the way that this is represented is by changing status to 'D', but “nobody in the system except this object has to know that, or to care.”

    And of course, “laziness is a virtue.”

    What do I want?

    has 'status' => ( traits => ['plugh'], # IF THIS IS NEEDED FOR THE MAGICK ... may_be_undef => 0, values => { 'status_alive' => 'A', ' status_dead' => 'D', }, handles => { # OR MAYBE SOME OTHER SUGAR-WORD ... 'is_alive' => 'status_alive', 'is_dead' => 'status_dead', }, );

    And my obvious thought is ... hasn’t this already been done by somebody else?   The assumption that surely somebody has, and that I just haven’t discovered it yet, is rather compelling.

Re: Moose goodness for status-code values?
by sundialsvc4 (Abbot) on Nov 19, 2011 at 01:05 UTC

    Unfortunately, no, that really doesn’t seem to be what I am looking for here.   In my example, the attribute being tested is (say...) status1, and we are looking for specific values such as 'F' or 'P', but what I am trying to “bury” is awareness (outside of the object itself) of just what these magic-values are.   And certainly to be sure that no values other than those in the list can be successfully assigned.

      I see a few potential problems with the strategy you describe here, perhaps they are related to why the Boolean module doesn't work the way you'd like out of the box. You might want to take another look though, it does help get you most of the way there.

      One problem is that you didn't follow the convention of storing a single bit of information using 0 for false/fail and 1 for true/pass. The easiest solution here is to go with the flow and use something like $record->status(0) for fail, and $record->status(1) for pass. Next easiest would be to define functions called pass and fail, so you can use them as barewords instead of 0 and 1.

      Or, you can have the user pass specific values such as 'F' or 'P', and still /store/ the value as a native boolean. You would have to write your own accessor, but it wouldn't be terribly complex, and what you are requesting is pretty unusual / dangerous style-wise, I'm not surprised there isn't yet a module to automagically create method names for each potential value of a variable in the namespace of it's containing class.

      Having said that, when you know you want to create them, you could just declare the accessor subs yourself along with the attribute in a Moose::Role, and then 'with' them into whatever class(es) you'd like, which is a little bit automagical.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://938893]
Approved by davido
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others learning in the Monastery: (5)
As of 2024-03-29 01:01 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found