use Perl

• Curious... (Score:1)

  by Adrian (66)

  .... why the trailing "no Moose"?
  • Re: (Score:2)

    by Ovid (2709)

    It removed the functions that Moose exports into your package. It would be annoying if someone tried to call $object->has :)
  • Re: (Score:2)

    by Ovid (2709)

    The lovely MooseX::Declare [cpan.org] lets you avoid even that (and it's an incredible module), but unfortunately, it's very alpha and has plenty of bugs. Still, look what it buys you:

    use MooseX::Declare;
    
    class BankAccount {
        has 'balance' => ( isa => 'Num', is => 'rw', default => 0 );
    
        method deposit (Num $amount) {
            $self->balance( $self->balance + $amount );
        }
    
        method withdraw (Num $amount) {
           
    • Re: (Score:1)

      by Adrian (66)

      > I can't wait until that's production ready.

      Ohhh. Shiny! :-)
    • Re: (Score:1)

      by rafl (7583)

      All MooseX::Declare does to not require you to unimport all Moose keywords (and possibly other imports) is

      use namespace::clean -except => 'meta';

      to remove all previously defined and imported functions (except for the 'meta' method Moose gives you) at the end of compile time. No need to wait for anything.
    • Re: (Score:1)

      by draegtun (6354)

      I can't wait until that's production ready.

      I think everyone who left the London Perl tech talk last night felt & thought the exactly same thing.

      Patience is a virtue!

      /I3az/
• What about ''? (Score:2)

  by autarch (914)

  I don't understand the bit about the final '' in your comment. I think a better way to do that is make method lazy and have the default be:
  
sub { $_[0]->name }

  • Re: (Score:2)

    by Ovid (2709)

    The reason for the final '' is that it put a string in the method, thus ensuring it would pass type validation. Your solution is much nicer. Thanks :)
• Ohh, Moose Golf! (Score:1)

  by Stevan (6065)

  So, in the interest of TIMTOWTDI, here is another approach that uses coercion to extract the params list from the controller object.

  package PIPs::QueryParams;
  use Moose;
  use Moose::Util::TypeContraints;
  use PIPs::QueryParams::Param;
  
  # I am assuming this is the name
  # of your controller class and
  # it is a non-Moose class, if it is
  # a Moose class, you can remove this
  # (assuming the class is already loaded)
  # because Moose does this for you
  class_type 'PIPs::Controller';
  
  subtype 'PIPs::ListOfParams'
     
• A code smell (Score:2)

  by autarch (914)

  Thinking about this example, there's a code smell in general with your use of BUILDARGS.

  BUILDARGS is really _not_ for munging arguments, it's there to allow for a constructor which doesn't take named argument, like
  
my $user = User->new($user_id);


  If you're using it to add extra arguments, consider using lazy default/builder, per my suggestion. If you're using it to coerce, use a coercion per Stevan's example.
  • Re: (Score:2)

    by Ovid (2709)

    OK, I'll buy the code smell argument because you have more experience with this than I do, but I don't understand. I like the lazy/default example, but Stevan's example is longer than mine and doesn't seem to buy me anything. Plus, as Stevan pointed out, it has the drawback of an apparently misnamed constructor pair. What am I missing?
    • Re: (Score:2)

      by autarch (914)

      The advantage of coercion is exactly what Stevan says, it lets you reuse that bit of logic across classes.

      The name mismatch is weird, but I'd probably just have people call the constructor like this:
      
PIPs::QueryParams->new( params => $controller->allowed_query_params );


      I honestly don't like _any_ of these options much myself, but I don't understand your APIs or problem domain well enough to come up with a better solution.

      There's just something about using BUILDARGS to do what coercion can do that st