Parrot's core PMCs have dozens of these operations, such as getting and setting integer, numeric, and string values. They support a clone operation, an invocation operation, an instantiation operation, and more. While some of these operations make little sense (invoking an Integer PMC throws an exception for obvious reasons), every PMC has to support them sufficiently that attempting to perform that operation should not cause the VM to crash.

Parrot's core PMCs are big wads of C code. All of these operations in Parrot's core PMCs are C functions gathered in a large table of function pointers. Every PMC type has one of these tables. Adding a new core operation to Parrot means adding a new function to every PMC table. Every new function added to the PMC table thus adds to the memory and startup costs of Parrot overall. Similarly, adding a new PMC type—even a specialization of an existing type—increases the memory and startup costs of Parrot overall because a new type needs an entirely new and distinct function pointer table.

These are implementation details quite solveable with some clever programming, but the most interesting point in my mind is how these implementation details have influenced the development of Parrot and Parrot languages. In particular, there's a subtle (and likely correct) belief in the project that adding a new PMC is an expensive operation in terms of Parrot's footprint and the management of its source code.

That's true to some extent, which is a shame, because Parrot's suitability as a VM for interoperable languages comes in no small part from the flexibility of the PMC system.

The cost of the belief in the heavy cost of new PMCs is that the core of Parrot takes advantage of far less polymorphism than it should. Consider the difference between a named function, an anonymous function, a method, a closure, a continuation, an exception handler, a binding to a shared library function, and a lazy thunk (perhaps a generator). You can invoke all of those items. You can pass in zero or more arguments. They can each return zero or more values. Yet they each perform very different mechanisms of control flow.

An ideal Parrot design would have separate PMC types for each logical type. A boring old named function which takes no parameters could avoid parameter passing code altogether, while the binding to a shared library function likely needs to marshall data to and from the appropriate ABI. A generator should be fast and lightweight, while an exception handler may have to manipulate control flow in interesting ways to resume an exception or at least resume at the appropriate place in control flow based on which exceptions it can handle and which it must decline.

Yet Parrot doesn't have multiple specialized PMC types representing all (or even most) of the necessary variants of invokable PMCs. It only has a handful. Those precious few would benefit from the judicial and pervasive application of the pattern Replace Conditional With Polymorphism.

Unfortunately, PMCs are far more expensive than they should be, and so it's cheaper to make the existing PMCs far more complex (and subsequently far more expensive on the individual level, not only the type level) than they should be. If PMC types were cheap, individual PMCs could be smaller and smarter and the entire system itself could have much stronger pressure toward simplicity.

Then again, writing an object system in C using native C data structures and dispatch mechanisms and language patterns governs what you can and can't accomplish cheaply and easily. One of the goals of the Parrot Lorito project is to reduce the tight coupling of Parrot's internals with C so as to make necessary changes in Parrot sufficiently inexpensive.

(Any metaobject system in, for example, Perl 5 would do well to consider these lessons.)

Parrot's core PMCs have dozens of these operations, such as getting and setting integer, numeric, and string values. They support a clone operation, an invocation operation, an instantiation operation, and more. While some of these operations make little sense (invoking an Integer PMC throws an exception for obvious reasons), every PMC has to support them sufficiently that attempting to perform that operation should not cause the VM to crash.

Parrot's core PMCs are big wads of C code. All of these operations in Parrot's core PMCs are C functions gathered in a large table of function pointers. Every PMC type has one of these tables. Adding a new core operation to Parrot means adding a new function to every PMC table. Every new function added to the PMC table thus adds to the memory and startup costs of Parrot overall. Similarly, adding a new PMC type—even a specialization of an existing type—increases the memory and startup costs of Parrot overall because a new type needs an entirely new and distinct function pointer table.

These are implementation details quite solveable with some clever programming, but the most interesting point in my mind is how these implementation details have influenced the development of Parrot and Parrot languages. In particular, there's a subtle (and likely correct) belief in the project that adding a new PMC is an expensive operation in terms of Parrot's footprint and the management of its source code.

That's true to some extent, which is a shame, because Parrot's suitability as a VM for interoperable languages comes in no small part from the flexibility of the PMC system.

The cost of the belief in the heavy cost of new PMCs is that the core of Parrot takes advantage of far less polymorphism than it should. Consider the difference between a named function, an anonymous function, a method, a closure, a continuation, an exception handler, a binding to a shared library function, and a lazy thunk (perhaps a generator). You can invoke all of those items. You can pass in zero or more arguments. They can each return zero or more values. Yet they each perform very different mechanisms of control flow.

An ideal Parrot design would have separate PMC types for each logical type. A boring old named function which takes no parameters could avoid parameter passing code altogether, while the binding to a shared library function likely needs to marshall data to and from the appropriate ABI. A generator should be fast and lightweight, while an exception handler may have to manipulate control flow in interesting ways to resume an exception or at least resume at the appropriate place in control flow based on which exceptions it can handle and which it must decline.

Yet Parrot doesn't have multiple specialized PMC types representing all (or even most) of the necessary variants of invokable PMCs. It only has a handful. Those precious few would benefit from the judicial and pervasive application of the pattern Replace Conditional With Polymorphism.

Unfortunately, PMCs are far more expensive than they should be, and so it's cheaper to make the existing PMCs far more complex (and subsequently far more expensive on the individual level, not only the type level) than they should be. If PMC types were cheap, individual PMCs could be smaller and smarter and the entire system itself could have much stronger pressure toward simplicity.

Then again, writing an object system in C using native C data structures and dispatch mechanisms and language patterns governs what you can and can't accomplish cheaply and easily. One of the goals of the Parrot Lorito project is to reduce the tight coupling of Parrot's internals with C so as to make necessary changes in Parrot sufficiently inexpensive.

(Any metaobject system in, for example, Perl 5 would do well to consider these lessons.)

That's the sign of a very good library or framework: the common things are easy and they resulting code is easy to understand, maintain, and extend.

Moose has a very nice feature of reducing the surface area of the APIs you create with it. You can declare a class with several attributes but only expose a few public getters or setters. The ability to use lazy initialization of attributes—as well as default values—allows the calculation of dependent attributes as needed.

Best yet, if you can arrange your classes in such a way as to provide their necessary attribute values when you call their constructors, you can treat your objects from the outside as immutable, and you're halfway toward inversion of control, if that's useful to you.

(Read more about Moose and immutability and the value of these features and designs in the Modern Perl book, available in several freely redistributable electronic forms.)

Think of all of this as not coloring outside the lines. While good art is aware of the structure and limitations of its chosen form and breaks those conventions when it makes for better art, good software is primarily a conversation mechanism where perhaps you don't want to try to outdo Pynchon or DeLillo or Wallace. Perhaps.

Contrast this mechanism of working with objects with the bean style as expressed in parts of the Java world: a class has several private attributes. Each of those attributes has public getters and setters which follow a standard naming convention. Objects interact with other objects by their conformance to a protocol and discovery and use of those getters and setters enabled by the magic genericity of reflection.

(Did anyone else hear a duck quack?)

For the convenience of allowing a dependency injection such as Spring or a web framework inspired by J2EE to manage some of the boilerplate of managing object instantiation or object lifespan or even mapping object data to and from strings for web or web request display, you not only give up the creation of your objects, but you expose their internal attributes behind a thin (and, be honest, autogenerated by your IDE when it pops up a warning!) layer of accessor method.

There is value in the loose and ad hoc adherence to a protocol of practice...

... but for a language which claims great maintainability benefits from forcing the use of static, manifest typing, you may encounter a fair few perplexing errors if you don't get the CamelCase type of your bean property just so. (Remember, reflection!)

While sometimes I do wish Perl 5 were stricter about types and signatures—certainly I look forward to using Perl 6's gradual typing for more projects—I have more sense of safety with the Perl approach, where we don't assume our language is completely safe by itself. We're a little more paranoid, and—at least in this case—I believe it leads to better designs.

methbody : '{' remember addimplicitshift stmtseq '}'
            {
                if (PL_parser->copline > (line_t)IVAL($1))
                  PL_parser->copline = (line_t)IVAL($1);
              $$ = block_end($3, op_append_list(OP_LINESEQ, $3, $4));
              TOKEN_GETMAD($2,$$,'{');
              TOKEN_GETMAD($4,$$,'}');
            }
    ;

addimplicitshift :
    { OP *selfsv      = newOP(OP_PADSV, 0);
      OP *rv2av       = newUNOP(OP_RV2AV, 0, newGVOP(OP_GV, 0, PL_defgv));
      OP *shift       = newUNOP(OP_SHIFT, 0, rv2av);

      selfsv->op_targ = (I32)Perl_allocmy(aTHX_ STR_WITH_LEN("$self"), 0);
      $$              = newSTATEOP(0, NULL,
                            newASSIGNOP(OPf_STACKED, selfsv, 0, shift));
     }
    ;

The second production is most interesting. It does the work of creating the Perl 5 optree you can see from running:

$ perl -MO=Concise,meth -e 'sub meth { my $self = shift; }'
main::meth:
7  <1> leavesub[1 ref] K/REFC,1 ->(end)
-     <@> lineseq KP ->7
1        <;> nextstate(main 1 -e:1) v ->2
6        <2> sassign sKS/2 ->7
4           <1> shift sK/1 ->5
3              <1> rv2av[t2] sKRM/1 ->4
2                 <$> gv(*_) s ->3
5           <0> padsv[$self:1,2] sRM*/LVINTRO ->6

You don't have to understand all of that, but you can see that this is obviously a tree structure. addimplicitshift creates the branch staring at nextstate (op 1) with a sibling sassign (op 6). Other productions have already set up the body of the sub and its lexical scope, so the call to Perl_allocmy only has to give the name of a new lexical ($self). Its return value is the location of the created variable in the lexical storage pad, so that the opcode to access the value of $self can retrieve it correctly.

With that lexical created before the parser parses the literal body of the method from the source code, any other references to $self refer to the lexical implicitly created thanks to the method keyword such that:

use feature 'method';

method oops
{
    my $self = shift;
}

... produces a warning:

"my" variable $self masks earlier declaration in same scope

I suspect there's a reasonably easy way to make the method keyword work nicely with projects such as MooseX::Declare in code such as:

use 5.014;
use MooseX::Declare;

method register(Str $name, Int $age) { ... }

... but despite the advantages of a method keyword in Perl 5, I've done about as much coding on this as I want to do without more support that it might eventually go into Perl 5.

You can do everything in that post manually in Perl 5. (You're better off using a module such as MooseX::MultiMethods to handle the plumbing for you, but the point stands.) That's the fallacy of the Turing tarpit and the Blub programmer: everything is possible, but language support makes certain constructs easy and obvious, and easy and obvious code tends to exist.

If you think about Tyler's post that way, you can squint and see a general language design principle at work. Let me belabor the point somewhat more. Consider how to declare a new class in Perl 5. You have multiple possibilities. A class is merely a namespace, so:

package My::Class { ... }

That's well and good, and it works. Now do it at runtime:

eval "package $classname { ... }";

Again, that works. Yet if you consider the Class::MOP approach, you can start to see the flaw:

my $class = Class::MOP::Class->create( $classname );

I admit the flaw isn't staggeringly obvious until you need to add methods to the class. Again, it's not awful in standard Perl 5:

sub My::Class::method { ... }

... or at runtime:

{
    no strict 'refs';
    *{ $classname . '::' . $methname } = $method_ref;
}

... but how ugly when compared to:

$class->add_method( $methname, $method_ref );

The difference is the design principle at work: specify policy, not mechanism. In other words, the problem with the standard Perl 5 approach is that the how of how you store a subroutine in a package overshadows the intent of the approach. What's important is not symbolic references to typeglob slots in packages which represent classes. What's important is adding a method to a class.

The same rule applies when specifying type constraints on function parameters or multidispatch candidates or even declaring classes themselves:

class My::Class
{
    method awesome_method { ... }
}

... because even as much as I know how to implement a language on top of a virtual machine (or how to compile a language to native code), at the point where I read this code, much less write it, I don't care about the mechanism. I care about defining the policy.

I wrote T::MO several years ago when I noticed a pattern in test code I'd written. I wanted to isolate a couple of cases of behavior to test all of the code paths within specific functions and methods. Invariably I took advantage of Perl's dynamism to construct objects which adhered to a specific protocol of behavior but which were under my direct control.

Think of it this way. You want to test the error handling code for a database abstraction layer. If the network connection goes away or if the remote process crashes, you want to retain the data and perform the appropriate logging and recovery.

How do you test that? You force a failure. No, you don't hire an intern to yank the network cable during your tests. You mock up the code which raises the "Wow, it's suddenly quiet in here!" exception.

This is where I wrote T::MO wrong. Instead of mocking just one piece of the underlying plumbing, T::MO encourages people to mock the entire system, from the faucets down to the sewer system. You do get more control over the process, but you can lose yourself in a sea of sweaty little details.

T::MO can be an invaluable tool. Sometimes it's exactly what you need, especially when you have to clean up a pile of legacy code written without good design taste. Even so, I wish I'd written Test::MockObject::Extends first to encourage people to mock only part of the behavior of an object. If your code is anywhere close to well-factored, you should be able to splice in the specific behavior you need, scalpel precise, and have confidence that the rest of the code, the real code you run when you run the code for real, behaves appropriately.

The more you need to mock, the more coupled (and, generally, the poorer) your design. The less you do mock, the better your tests.

package Cat;

use Class::Struct;

struct( name => '$', age => '$', diet => '$' );

You don't get all of the benefits of Moose, but you do get attributes and accessors. You also get a default constructor.

Of course, the default constructor reads something like:

{
    package Cat;
    use Carp;

    sub new
    {
        my ($class, %init) = @_;
        $class = __PACKAGE__ unless @_;
        ...
    }

    ...
}

If that emboldened line is curious to you, it's curious to me too. I saw a note in one of the test files somewhere suggesting that the purpose of this was to allow you to write:

package Cat;

my $cat = new();

I don't know why you'd do that, however. In what kind of object design does it make sense to create objects of a class from within that class? (That seems like a violation of responsibilities to me.) You can also write:

package NotCat;

my $cat = Cat::new();

... though that's exceedingly fragile. For one thing, it implies that you could also write RobotCat::new()—assuming that RobotCat extends Cat, but avoiding method dispatch for calling a constructor means that RobotCat had better provide its own new() which behaves as a function as well as a method. (Even if you somehow convinced the subclass to inherit the superclass's function through some sort of exporting scheme, the hardcoded __PACKAGE__ would hurt.)

Hardcoding a method dispatch as a function dispatch means that the maintainers of Cat are not free to change how Cat provides its constructor, much for the same reason.

Woe unto you if there's an inherited AUTOLOAD somewhere.

I realize that in 1994 or 1995, people who wrote OO code in Perl 5 might have had familiarity with OO in C++ (where this syntax makes a little more sense) or, perhaps, Java where the indirect constructor call (the my Cat $cat = new Cat; is prevalent), but the benefit of hindsight is that experienced Perl 5 programmers can look back on this API a decade later and cringe at its potential for misuse.

If you're lucky, everything will go right—but what kind of a defensive programmer relies on luck when designing an API?

These are simple, well-understood problems, with well-understood solutions.

I don't want to poll sites more frequently than they allow, so I'm happy to use LWP::RobotUA to fetch the feeds, as it respects the robots.txt protocol for well-behaved spiders.

I also want to skip processing if the feeds remain the same between fetches, so I want to use LWP::UserAgent::WithCache, which checks HTTP headers such as Last-Modified/If-Modified-Since and ETag/If-None-Match for modifications.

Unfortunately, both are subclasses of LWP::UserAgent, and both expect to be at the same level of a complex inheritance hierarchy which forms all of LWP in Perl.

Here is the object lesson for people desigining software. If you intend other people to reuse your software as components, such that you can't predict how other people will use it, remove as many unnecessarily hard-coded dependencies as possible.

If I were to redesign this part of LWP, I'd make the caching behavior and the robots.txt-respecting behavior into separate behaviors, perhaps runtime roles. I'd rewrite the LWP::UserAgent constructor to use a plugin system, where instantiators could provide an optional (and ordered) list of behaviors with which to decorate the $ua object. Obviously the behavior I need is first to check the cached copy and then check the robots.txt rules and then use normal HTTP access, but why hard-code these behaviors?

There are plenty of mechanisms (CLOS method modifiers, the Decorator pattern, dependency injection) to work around this problem, but for now my solution is to subclass LWP::UserAgent::WithCache, override its constructor, and manually inherit from LWP::RobotUA.

(For all of the faults of Java's IO model, it handles this problem well. Its defaults are awful, and it exposes too much complexity, but the Decorator pattern works effectively. PerlIO works in a similar fashion with much better defaults. This HTTP fetching problem is in the same category; note how a similar model could handle proxying, compressed output, anonymizers, and filtering with ease.)