perigrin

#   class RecommendationTracker
#     def add_recommendation(recommender, business)
#       has_recommender_recommended_business?(recommender, business) do
#         raise StandardError, 'You may only recommend the same business once.'
#       end
#
#       @recommendations[business] << recommender
#     end
#
#     def recommendation_totals

perigrin

Moose Hackathon Agenda

• Traits in C::MOP
• removing T::E from Moose/MOP
  • adding lives_ok/dies_ok to Test::Moose
• merging C::MOP and Moose
• Antlers
• merging MooseX modules into Moose and/or core
  • MX::AH into core
• MooseX::Traits -> Moose::Traits

perigrin

use 5.10.0;
use MooseX::Declare;
use MooseX::Getopt;

class Dice::Game with MooseX::Getopt {
    use Number::Format qw(format_price);

    has plays => (
        isa           => 'Int',
        is            => 'ro',

perigrin

So I know this has come up before but I can't see where I've mentioned it and stevan just asked me to blog about it. One of the frequently requested features in Moose is for attributes to default to having some kind of accessor either `is => 'rw'` or `is => 'ro'` depending on the preference of whomever is making the request. This is because Moose defaults to *nothing* if you don't tell it what you want. I just ran into a situation where *either* default would lead to potential bugs in application.

Our application has a queue that when it hits a high-water-mark will trigger processing on the queue and then reset the queue. This isn't exactly a *common* design pattern but it should be at least a familiar one. Here is the attribute definition for the queue:

    has queue => (
        isa       => 'ArrayRef',
        lazy      => 1,
        default   => sub { [] },
        clearer   => 'clear_queue',
        metaclass => 'Collection::Array',

perigrin

# $ tweet Hi mom!
#
# Put this in ~/.bashrc or wherever.
# If it doesn't work, make sure your ~/.netrc is right
#
# (Thanks to @anildigital and @grundprinzip for curl-fu)

function tweet {
  curl -n -d status="$*" https://twitter.com/statuses/update.xml --insecure &> /dev/null
  echo "tweet'd"

perigrin

=pod

=head1 NAME

Moose::Manual::Contributing - How to get involved in Moose

=head1 GETTING INVOLVED

Moose is a pretty open project and we are always willing to accept bug fixes,
more tests and documentation patches. Commit bits are given out freely, and

perigrin

New branching layout for Moose/Class-MOP

main branches:

master
stable
branches
topics

people:

perigrin

Ovid [linked][1] to [a blog post][2] about the evil's of inheritance. The post makes an excellent case for the dangers of inheritance for behavioral composition. However I knew he was running into a problem when his first example still used inheritance to denote [Type polymorphism][3]. That's ultimately my problem with his "solution" to inheritance.

His final example however does not use inheritance, translating it a bit to something [vaguely Perl-like][4] you get.

class Ball extends MovieClip {

perigrin

dispatcher => (
    '/'      => 'index',
    '/login' => resource(
        representations => {
            'text/html' => sub {'<h1>Comming Soon</h1>'}
        },
    );
);

resource index( Request $r) with(

perigrin

$perl -MO=Deparse -e'for (@{ [qw( 1 2 3 )] }) { print $_++ }'
foreach $_ (@{['1', '2', '3'];}) {
    print $_++;
}
-e syntax OK


$perl -MO=Deparse -e'for (qw( 1 2 3 )) { print $_++ }'
foreach $_ ('1', '2', '3') {
    print $_++;