Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked

Re: Moose Design Thoughts (Traits)

by stvn (Monsignor)
on Dec 22, 2010 at 20:55 UTC ( #878664=note: print w/replies, xml ) Need Help??

in reply to Moose Design Thoughts (Traits)

Looks good to me, I do the same thing with the 'Hash' trait all the time myself. My only recommendation is to remove the 'auto_deref' as that feature is no longer recommended, instead use the 'elements' handler which will do the exact same thing.


Replies are listed 'Best First'.
Re^2: Moose Design Thoughts (Traits)
by perigrin (Sexton) on Dec 23, 2010 at 06:42 UTC
    not the exact same thing, the same thing except for the context sensativity ... which is why auto_deref is no longer reccomended in the first place
Re^2: Moose Design Thoughts (Traits)
by Cagao (Monk) on Dec 23, 2010 at 09:36 UTC

    Good point, I started using the 'values' handler to grab a list of the values and shouldn't/won't be accessing the whole hash directly anyway.

    I set the contents in the class by passing in $self->_industries( \%selected ); but from then on using the trait handles.

    My previous implementations would have just stored the values in an array-ref, the move to using a hash is so I have quicker lookup with the ID of the values.

    My hash looks like this btw, incase it makes a difference...

    $obj->_industries( { 17 => { id => 17, name => 'foo' }, 26 => { id => 26, name => 'bar' }, } );

    There is obviously a duplication of the IDs, but that's minimal, and keeps the code that uses it simpler, rather than having to carry the ID AND the object around.

    That's the only down-side I can think of.

Re^2: Moose Design Thoughts (Traits)
by Cagao (Monk) on Dec 23, 2010 at 09:39 UTC

    btw, is the use of auto_deref no longer recommended in general, or only with Traits?

    I use it everywhere else with basic ArrayRef[] types.

      It is pretty much no longer recommended anywhere because it (ab)uses context and returns array/hash ref in scalar context and an array/hash in list context. While this is actually a fairly common idiom in Perl which I myself am long guilty of (ab)using (heck I even wrote the original auto-def code), it really is evil and should be stopped. The problem is that Perl context sensitivity can easily be the source of annoying and difficult to spot bugs, like for instance ...

      # normal usage, works just fine ... my @foo = $obj->foo; my $foo = $obj->foo; # but ... $other_obj->bar( foos => $obj->foo ); # whoops! # should actually be the more ugly ... $other_obj->bar( foos => scalar $obj->foo );
      While it might seem trivial, it really can be difficult to track down sometimes, especially when this is your primary accessor. But of course, it is nice to not have to manually de-ref all the time (Perl 5.13++) which is pretty much why the Hash trait and Array trait both have an 'elements' to delegate to that returns the derefed item in a non-context sensitive way.


        Thankfully I've actually started to move to drop 'wantarray' at the end of my subs for those very reasons.

        I think I'm much happier for a list to always be returned as a list, rather than, as you say, bizarre behaviour at times.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://878664]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (5)
As of 2018-03-22 05:16 GMT
Find Nodes?
    Voting Booth?
    When I think of a mole I think of:

    Results (273 votes). Check out past polls.