use Perl

If you didn't buy at Crazy Matt's Discount EMPORIUM! YOU PAID TOO MUCH!

I wasn't aware that the extends needs to be in a BEGIN block unless you really do have code which needs to happen at BEGIN time. Am I wrong? (Could be).

You're not wrong. Extending the parent class needs to happen at compile time in Catalyst because as dagolden mentions elsewhere Catalyst choose once upon a time to support sub foo : Path(/) { } syntax. The nature of that syntax and how Perl goes about making it "work" requires your class hierarchy to be resolved at compile time ... hence the BEGIN.

I mean $.callsame rather than .callsame. Thanks to TimToady and TiMBuS for clarifying things at least enough that I understand that much.

Also playing about some I came up with something nearly identical using MooseX::Declare's syntax.


role POC::TestAnnouncer {
        use mro;

        method test ($project) {
            announce-start-of('test', $project{name});
            my $result = $self->maybe::next::method($project); # callsame
            announce-end-of('test', $result);
            return $ret;
        }
}


I'm however unsure if callsame is implicitly a method dispatch or not. masak's example makes it seem like it is but the documentation is spares and semantically it seems like it should at *least* be .callsame if it's got an invocant.

The Moose version Frew posted uses Roles. So applying this "mixin" at Runtime to an instance will also derive an anonymous subclass with the Role applied and re-bless an instance into that subclass.

All metaphors are lies.

I prefer to think of them as useful fictions that illuminate a particular aspect of the truth. It is why good fiction is more true than bad non-fiction.

With that said, the internal implementation of an object system (especially a metaoperator protocol) won't match the problem domain of user code

Nor should they. MOPs especially are design to model the problem domain of an Object System. I've had a lot of serendipity about this recently, I hope I can get it all into my talk at YAPC which is about exactly this.

The Perl Oasis team would like to announce the Schedule has been posted for Perl Oasis 2010. We have 15 speakers from 3 continents giving 9 hours of talks, culimating in a keynote by the Enlightened Perl Organisation Secretary Mark Keating (mdk).

That example of MooseX::Declare like code is well intentioned but I (personally) think *horrific* for proving your point.

        function morning (Str $name) {
                say "Good Morning $name"
        }

This won't piss off the people who think you're pushing OO at them.

Attempting a definition of a "God Object"

Any object that implements a model for more than one concept simultaneously.

To take your "car" analogy for a second, you don't drive just a car. The interface presented to you delegates the actions you make to other components you don't have to think about yes, but at no point are the Engine Block, Steering Assembly, Chassis or Wheels wholly consumed by the "car". There are even those of us who prefer cars that make you *more* aware of this (manual transmission for example) rather than less.

Roles aren't really re-usable components, they're more like an alloying material. Adding carbon to iron provides you with a new stronger material steel. Steel is a new basic block to build components out of. Carbon and iron are useful in other alloys (and individually ... the analogy and Perl5/Moose's object model break down here), and can be reused ... but they're not the same as steel.

So yes Roles make building God objects easier. I can't see that they fundamentally affect the problems with God objects. Those problems stem from the fact that your single Class/Object is trying to model more than one concept. I think nothingmuch's point is delegation provides a cleaner way to compose two different concepts than either Roles or Inheritance.

Finally using this definition the problem with Ravioli Code is that the concepts are modeled across more than one class, making it difficult to understand how the model is composed at all.

It's really the only sensible answer. Someone please inform the Python community that they can steal our angst now.

November 25th is the last day for the Perl Oasis special Group Rate. The rate is $75 USD / night for what according to other sources is a $135-$150 / night hotel room.

Perl Oasis is a one day workshop in Orlando Florida focusing on Modern Enlightened Perl. This year we have speakers from three continents, and the entire Perl spectrum speaking. The Call for Speakers is still open so you can submit your talk as well!

It seems to me that the example you give is ultimately a poor test. You’re relying upon an implicit feature of the testing interface to test for explicit behaviors of your code. As a person new to your project how I am supposed to know that list() is only ever supposed to return two elements? Sure the tests fail but how do I know that the tests were correct in the first place?

By making an explicit test for the explicit behavior, I can communicate to someone else that I’m expecting list() to only ever return two elements, and that doing differently is actually changing known behavior.

Say what you will bout done_testing, you may like it or you may not (personally I hate having to update my test count, but I was willing to use no_plan). Relying upon implicit behavior of your environment to provide you with explicit behavior of the code your writing is a bad practice.

Not to mention how much existing code this will break and/or start warning for.

Who's going to start championing the patch to P5P that we need this feature in the Language?

One of Moose's driving goals (which we do lose site of occasionally) is that it is Perlish. This feature (right or wrong) is not how Perl currently interprets overriding inherited methods. There are several places where Moose tries to be more strict about things than default Perl (strict/warnings enabled by default for example, though 5.11 enables strict as part of "use 5.11") and several places where things that Stevan and most of the Moose Cabal would *want* to be more strict are specifically not because it's not the Perlish way (having new() die when called as an instance method for example).

This is one of those places where I would heavily suggest that we need to stick to where being consistent with the language is important. If Perl were to start warning about overriding methods in subclasses without an explicit notation, then I would *certainly* agree that Moose could and should start doing so for Roles. Because it doesn't I think it's improper for (default) Moose to impose that burden upon developers who use Moose.