The Room

So I’ve just release a new JSON::Any. Back in January when I made the last release, Marc Mims (the new maint for Net::Twitter) had a bug in JSON::Syck which Audrey decided not to fix since JSON::Syck is deprecated. This is fair, she’s the maintainer and is allowed to deprecate things when there are better alternatives on CPAN (which honestly JSON / JSON::XS are).

JSON::Any has a feature where you can explicitly load a list of modules by passing them in

use JSON::Any qw(XS Syck DWIW)

and a default list that will try to implicitly load modules. In the 1.19 release I removed JSON::Syck from the implicit list entirely. This meant that you’d have to explicitly pass it in if you wanted to optionally use JSON::Syck. This sounded reasonable at the time, but turned out to be a poor decision. If all you have is JSON::Syck installed, then JSON::Any is useless. This turned up in a bug to Test::JSON.

So JSON::Any 1.20 is on it’s way to CPAN, and it now includes a Deprecation feature where modules that JSON::Any supports but we don’t want to blindly trust are loaded via a deprecation list with a warning. This is a subtle prod to entice people to upgrade. Currently the warning is non-optional but I’m formulating different ideas on how to enable/disable the warning in different contexts, but like anything with JSON::Any it may not happen until someone complains loudly … or with a patch.

So YAPC::NA is over. I’ve mostly recovered from the Moose Flu that seems to have circulated around at it. I’ve posted my slides for both XML::Toolkit and the EPO-EC talks. The first went “okay”, while I’d been doing a lot of work with it the weeks before YAPC I think that adding slides to the talk sort of brought down the excitement a bit. The second talk however went really well. Granted it had a 50 minute introduction by mst (supposedly it was his own talk on standards as socially transmitted diseases but we all know he was just introducing me), and that can’t hurt. Anyway I hope to be posting more about the EPO-EC talk and what is going on shortly but first I need to catch up with work.

UPDATE: Mark Keating has posted video of my EPO-EC talk online.

I’m off to YAPC tomorrow. I’m giving two talks on Tuesday and I haven’t yet finished my slides (though I do think I have some clue what I’m gonna talk about). This is the first time in six years I’ve spoken at something as large as a YAPC and I’m starting to feel a little nervous. Unlike six years ago however this time I’m expecting to see a bunch of faces that I know. Hallway tracking OSCON last year was one of the better experiences I’ve had in my career and I’m hoping this is more like that. Either way I’m not expecting to get my (ir)regular posting back again until after next week … but then again I may brain dump stuff about XML::Toolkit since it’s the topic of one of the talks and has been getting a ton of work this week.

I’ve just released XML::NamespaceSupport 1.10, with fixes to it’s build system. I’ve had it soaking as a dev release for the last week or two, ever since I noticed it was #6 on Adam Kennedy’s Fail 100. I had to chase down Robin Berjon and get him to delegate co-maint, but it was a simple enough once that happened. One down, 99 to go.

With the blessing of Barrie Slaymaker, I’ve released a new version XML::SAX::Machines. This is the first release in 5 years, and fixes a two year old RT ticket about the use of psudo-hashes (which are deprecated and removed in perl 5.10). I plan on trying to resolve the other issues in RT and working with it and my own XML::Toolkit as time goes by. If you don’t know what SAX Machines are you should really check out Kip Hampton’s article on XML.com.

Ovid has discovered another “bug” (and by “bug” I mean documented feature ;) ). He has code that effectively does:

class MyClass {
    has my_method => ( default => 1);
}

and then is surprised when MyClass->new->my_method fails. In his case it was hidden by an inheritance hierarchy. This bites many people new to Moose, and there has been a suggestion to make has default to something. The problem with a default for has is that there are valid uses for not providing an accessor.

class Toy {
    has sound_chip => (       
        default  => sub { SoundChip->new() }
        handles  => [qw(beep)],
    );
}

Then you can say Toy->new->beep. We never want people to even know that a Toy uses a SoundChip object because it’s entirely encapsulated. The only external exposure right now is someone could in theory say Toy->new(sound_chip => $geigerCounter). We can entirely encapsulate this with:

class Toy {
    has sound_chip => (
        init_arg   => undef, # disable new( sound_chip => Object )
        default    => sub { SoundChip->new() }
        handles  => [qw(beep)],
    );
}

A more extended example (and closer to stuff I’ve seen in production) uses Roles.

role TemperatureAdjustments { requires 'adjust_temperature' }

class Furnace {
    has thermostat => (
        does     => 'TemperatureAdjustments',
        handles  => 'TemperatureAdjustments', # proxy the entire role
        default => sub { StandardThermostat->new() }
    )
}

then later you say:

my $furnace = Furnace->new();
$furnace->adjust_temperature("+1F");

Once the widget is integrated into the Furnace as a thermostat there is no valid use case to access it directly. Providing a default for has means that this is no longer simple and elegant. But! you say, shouldn’t we optimize for the most common behavior? Yes we should, and you’d be right to change the default for has if it worked the way Ovid assumed it does.

class MyClass {
    has my_method => ( default => 1);
}

This starts with entirely the wrong assumption at my_method. You’re not declaring a method here, you are declaring an attribute. Attributes are state and state != behavior. Moose allows you to also define behavior via has. is, reader, writer, clearer, predicate, handles, and lazy_build all enable some kind of behavior in your class.

By making a default for is what you’re doing is creating action at a distance and invisibly coupling the definition of behavior with the definition of state.

UPDATE: Fixed some typos, thanks to Shawn Moore, Matt Trout, and Stevan Little for proofreading and editing.

One of the reasons that Moose really works is that it’s a layer of abstractions. At the bottom you have Perl’s native OO layer which is … let’s be charitable and say “bare bones”. On top of that Stevan wrote Class::MOP which standardizes the lower layer, cleans up the edge cases, implements some best practices, and gives you a massive level of introspection over everything. On top of Class::MOP is Moose which brings in a new layer of features including Roles, Delegation, Type Constraints and the other goodies you’ve heard so much about. On top of Moose are things like MooseX::Declare and the rest of the MooseX:: namespace that can extend the features that Moose provides in new directions.

This stack works precisely because it is a stack. Nested layers of abstraction means you have a consistent base and you can play TIMTOADY on top of it as much as you like but you get the consistency of a stable API at the center. Eventually the new layers on top become a base for layers atop them. The current discussion about the Perl release system seems to me to really be about this idea. chromatic pointed out that Rakudo has had more stable releases than Perl5 in the time since the Perl6 announcement was made. This is true, but Rakudo’s idea of stable is smaller stack of abstractions than Perl5’s. Rakudo doesn’t ship 114 external modules. It doesn’t even ship 100% of the spec’d Perl6 features. Claiming that Rakudo’s concept of stable is comparable to Perl5’s is disingenuous. I’m sure chromatic was trying to highlight this discussion on what stability is rather than trying to troll with statements full of FUD, he’d be the first to defend Perl if someone else were to make this statement.

The right answer is probably a middle ground. Lots of people agree that Perl should ship a smaller Core set of modules, perhaps a smaller set of core features would help too, something to enable more externalizing of hooks like Devel::Declare. I’m already failing at my volunteer effort to drive the first part, I doubt I’d be the right person for the second (but I’m willing to try).

This same idea comes up as well with the comparison of stability between Module::Build and Module::Install. Those on the Module::Build side point out that having a single API means that everybody is on the same page and that you can trust all installers are equal. The Module::Install people tend to point out that not all distributions are equal and that having everybody conform to the same API causes problems when you try upgrading that API (not everything is installed equally everywhere).

It seems to me that the answer is to have a core API (Module::Build, EUMM it doesn’t matter), and a stack of abstractions on top of that where you can do experimental extensions. Module::Install currently does this on top of EUMM.

This is hypothetical so don’t read too deeply into it. Let’s say you’re walking across town carrying some heavy bags. Let’s also say that you’re walking in front of a bicycle shop and the owner is out front sweeping. Let’s say that the owner offers to give you one of his cheaper bicycles for free because (he says) he’s been in your situation before and knows how much easier it would make things if you could stick the stuff in the panniers and just ride to where you’re going. Let’s say that while you can ride a bicycle, the model he has has some features you don’t understand, and it makes you worry you may not be able to ride this bicycle properly. When you bring this up the owner apologizes and says that the bicycle is one of his own design but he hasn’t gotten to writing a manual for the features. Here’s the quiz part, do you a) use the bicycle, taking a chance later to try out the features and write down what they do for the owner as a thank you for giving you a free bicycle when you needed it, b) thank the owner for his kind offer but politely decline because you’re concerned that the features may not work properly for you without a better understanding of what they do, or c) complain that the owner doesn’t really care about his customers because he is spending time sweeping in front of his store rather than working on the documentation?

Hint a) and b) are things my mother would be proud of, c) would have gotten me walloped. I’m ashamed of some people’s sense of entitlement. I hope I raise my children better.

Ovid recently asked if there was ever a reason to use Inheritance over Composition. Stevan answered that question rather eloquently but the whole thing has me thinking about the relationship between Classes and Roles.

Object Orientation has no bearing on the real world. It’s framework for building metaphors that hopefully help programmers better model reality. You define Classes to represent some set of objects that reflect your problem domain, and then use those classes to manipulate the domain to get answers or control systems or mutate weasels. Roles come in to help compose re-usable bits of behavior into the system. In languages without Roles this composition of behavior is often achieved through the use of Abstract Classes, or Classes that don’t represent an object, but represent some quality of an object.

To answer Ovid’s question requires a deeper exploration of where Roles and Classes differ. At first blush Classes and Roles are very similar. They both bundle up a set of data and behaviors (sometimes this set is empty, see below) a namespace or type for reusability. The difference, and this is crucial, is that Classes can be instantiated and Roles cannot. That is Classes reflect something concrete in your model, something that has an existence and can be manipulated. Roles don’t, they’re always ethereal and abstract, and only gain realization when composed with a Class.

Sometimes a Role and a Class do nothing more than establish a Type or namespace. An example is the NoGetopt trait (A trait in Moose is roughly a Role applied to a metaclass) and metaclass which are both empty. The NoGetopt metaclass is a subclass of the Attribute metaclass with the NoGetopt trait applied. Attribute metaclasses are part of the Moose domain model, they are concrete and instantiated, the only way to replace a metaclass is with something equally concrete. The ability to subclass Moose::Meta::Attribute gives us the flexibility to apply the NoGetopt trait at runtime. Otherwise we would have to design all the combinations of Roles and Classes up front, or run into situations where we need to either implement everything as a Role composed against an empty class (why have classes then?), or run into situations where we would have to replicate a class to define a new composition of roles (Moose::Meta::Attributes::WithNoGetopt) because there are different situations where different combinations are needed in an instance.

Note that the NoGetopt trait exists so that you can apply it to an anonymous subclass of a metaclass. This means that if you already have a subclass of Moose::Meta::Attribute, Moose will (behind the scenes) create a anonymous subclass and apply the NoGetopt trait to it.

Finally we can see this sort of logic play out in the ad-hoc way people choose to decide the class/role relationship. Jonathan Worthington commented :

"Dog does Walk" sounds much natural than "Dog is Walker" and that "Dog is Animal" 
is more natural than "Dog does Animal"

Walking is generally an abstract concept, however we often say we are gonna take the dog “for a Walk”. Which suggests that in some models a Walk may be a concrete concept. Relying upon ad-hoc “does it sound right?” heuristics means that your model stops reflecting the needs of the domain.

If a thing represents a piece of your domain you need to manipulate, and is a specialization of another piece of your domain you need to manipulate then in general you want to use inheritance.

I was reading a blog post recently that mentioned the Dawkins Weasel program. I have always wanted to play around with Genetic Algorithms and this one seemed simple enough to hack at for a few hours. Four hours later I think I have something that can illustrate Modern Moose nicely ( Spacecataz this is specifically for you, seduce you back away from Python). NOTE: I have re-arranged some stuff to make this discussion a little easier. The source code will show the right order and will run properly.

#!/usr/bin/env perl
use 5.10.0;
use MooseX::Declare;

Like any good perl modern script we start out with a #! line, state that we’re gonna use a Modern Perl (5.10+), and we’re gonna use some of the new sugary syntax from MooseX::Declare

Now in the code I pilfered the algorithm from we have some global parameters. Matt Trout likes to call Singleton objects “God” objects, so we’ll just borrow that nomenclature here. Technically this isn’t a Singleton either, but we’re gonna abuse things a bit for the sake of a pun.

class GOD {
    use constant TARGET        => 'METHINKS IT IS LIKE A WEASEL';
    use constant MUTATION_RATE => 0.09;

    sub DEFAULT_STRING() { join '', map { RANDOM_LETTER() } 0..(length TARGET) -1 }
    sub RANDOM_LETTER() { ( 'A' .. 'Z', ' ' )[ rand(27) ] }
}

DEFAULT_STRING and RANDOM_LETTER are some utility methods we’ll use in a bit.

So now that we have God we can create the World. Our World is basically a container for evolving generations of objects (in our case Weasels). We have a small world, it can only hold 50 Weasels at a time.

class World {
    use constant SIZE => 50;

Our world is also a harsh mistress, there can only be one generation alive at a time. (Though all is not lost as we’ll see, Weasels can worship their ancestors). We keep an ArrayRef of Weasels around.

    use MooseX::AttributeHelpers;

    has current_generation => (
        isa        => 'ArrayRef[Weasel]',
        is         => 'rw',
        auto_deref => 1,
        builder    => 'first_generation',
        metaclass  => 'Collection::List',
        provides   => {
            first => 'best',
        }
    );

We’re useing MooseX::AttributeHelpers to provide us with a simple helper method that returns the “best” Weasel in each generation. We know its the best because our world keeps Weasels sorted by their fitness.

    sub _generate (&) {
        [ sort { $a->fitness <=> $b->fitness } map { $_[0]->() } 1 .. SIZE ];
    }

    method first_generation {  _generate { Weasel->new }    }
    method new_generation {
         $self->current_generation( _generate { $self->best->spawn } );
    }

There are two times we want to generate a new generation of Weasels, at the dawn of the world when the current_generation attribute is first initalized, and when we call new_generation. At initalization we create an Ur-Weasel, every other time we let the best Weasel of it’s generation breed. It’s good to be fit.

So now that we’ve covered how generations work, the Way the world run’s should be obvious. Keep generating new_generations until the Kwisatz Haderach is born.

    method run {
        $self->new_generation() until $self->perfect_offspring;
    }

How do we know when we have perfect offspring? When the best of our generation is perfect.

    method perfect_offspring { $self->best->perfect }

Finally so that the runtime isn’t totally boring waiting for the world to end, we use a method modifier to tack on some output letting us know who the best in each generation is.

    after new_generation { say $self->best->to_string };
}

So let’s look at the population of our world. Ah the Weasel, the most quintessential of GOD’s creations. Weasel’s do one thing in life, they breed mutants. So our Weasel class composes the Role NonLockingMutations which we’ll gloss over for a bit and just say “Weasels can evolve”.

class Weasel with NonLockingMutations {

Now I said before that Weasels have a strong sense of ancestory, even though the World only knows about one generation of Weasel at a time, each weasel knows exactly who it’s parent was, and what generation they belong to.

    has parent     => ( isa => 'Weasel', is => 'ro', );
    has generation => ( isa => 'Int',    is => 'rw', builder => 'my_generation' );

    method my_generation {
        return 0 unless $self->parent;
        $self->parent->generation + 1;
    }

They also have a little genetic string. Which they inherit from their parent (unless they’re the Ur-Weasel in which case they get it from GOD).

    has string     => ( isa => 'Str',    is => 'ro', lazy_build => 1 );

    method _build_string {
        return $self->inherit_string if $self->parent;
        return GOD::DEFAULT_STRING;
    }

Finally Weasels can breed, they each have one child and teach it who its parent is, and they know how to tell the World about themselves.

    method spawn { Weasel->new( parent => $self ) }

    method to_string {
        "${\sprintf('%04d', $self->generation)}:${ \$self->string } (${\sprintf('%02d', $self->fitness)})";
    }
}

Now we get to the interesting part of this, the reason we created our own little universe. Weasels would never become perfect if they couldn’t Mutate.

role Mutations {
    requires qw(string parent mutate);

In our universe fitness is determined by the Levenshtein distance of the Weasels string from GOD’s target.

    use Text::LevenshteinXS qw(distance);

    has fitness => ( isa => 'Int', is => 'rw', lazy_build => 1 );

    method _build_fitness { distance( $self->string, GOD::TARGET() ) }

We know we’re perfect when our distance from GODs TARGET (our fitness) is 0.

    method perfect { $self->fitness == 0 }

Mutations are also where we inherit strings from our parents. Strings are never inherited cleanly, there’s always a chance at mutation. That chance however depends on the mutation mechanism we’re using

    method inherit_string {
        return join '', map { $self->mutate($_) }
            0..(length $self->parent->string) - 1;
    }
}

Mutations in our world come in two flavors, Non Locking Mutations mean every character is free to mutate no matter if it already matches the corresponding character in the TARGET. Locking Mutations don’t change characters that already match.

Here are the implementations for each, they’re pretty straight forward, and mostly the same. If we haven’t been hit by a cosmic beam (ie a random number is less than GODs MUTATION_RATE), return that character unmodified. Otherwise return a new random character.

role NonLockingMutations with Mutations {
    sub mutate {
        my $target = substr($_[0]->parent->string, $_[1], 1);
        return $target unless rand() < GOD::MUTATION_RATE;
        return GOD::RANDOM_LETTER;
    }
}

The only thing that LockingMutations changes on this is if we already match GODs TARGET, return the current character.

role LockingMutations with Mutations {
    sub mutate {        
        my $target = substr($_[0]->parent->string, $_[1], 1);
        return $target if $target eq substr(GOD::TARGET, $_[1],1);
        return $target unless rand() < GOD::MUTATION_RATE;
        return GOD::RANDOM_LETTER;
    }
}

That’s it, everything is implemented. We start the world running and see our results

World->new->run;