Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

perigrin (3495)

perigrin
  {chris} {at} {prather.org}
http://chris.prather.org/
AOL IM: marceusx (Add Buddy, Send Message)

After Middle School Chris bounced through various high schools around the state of Florida for a bit. He ended up getting a BA (in English) from the University of Central Florida at about the time others his age were getting their MAs. His (now) wife, their child, and he went to Europe for a bit (there was a programming job in Scotland) and came back unemployed where upon he got offered a job in St. Paul. He moved on from that job after a few years to one where he was paid to do the things he previously did as a hobby. That sounds much more exciting than it really was. Really his life is based on two kids, two cats, and a bunny.
+ -

  Comment: Re:Matt Trout, aka mst, is insane (Score 1) on 2010.08.11 13:04

by perigrin on 2010.08.11 13:04 (#72288)
Attached to: Matt Trout, aka mst, is insane

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

Read More 17 comments
Comments: 17
+ -

  Comment: Re:Moose Notes (Score 1) on 2010.08.03 10:49

by perigrin on 2010.08.03 10:49 (#72237)
Attached to: Protesting the Moose with sugary alternatives

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.

Read More 17 comments
Comments: 17
+ -

  Comment: Re:And with Moose in Perl 5 (Score 1) on 2010.07.07 23:26

by perigrin on 2010.07.07 23:26 (#72154)
Attached to: Dreaming in mixins

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

Read More 7 comments
Comments: 7
+ -

  Comment: Re:And with Moose in Perl 5 (Score 1) on 2010.07.07 22:03

by perigrin on 2010.07.07 22:03 (#72153)
Attached to: Dreaming in mixins

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.

Read More 7 comments
Comments: 7
+ -

  Comment: Re:And with Moose in Perl 5 (Score 1) on 2010.07.07 21:29

by perigrin on 2010.07.07 21:29 (#72152)
Attached to: Dreaming in mixins

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.

Read More 7 comments
Comments: 7
+ -

  Comment: Re:Mostly Agree, but.... (Score 1) on 2010.06.04 19:40

by perigrin on 2010.06.04 19:40 (#72020)
Attached to: Moose, DBIx::Class, and the _new_ OO

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.

Read More 2 comments
Comments: 2
+ -

  Journal: Perl Oasis 2010: Schedule Posted on 2009.12.24 2:10

Journal by perigrin on 2009.12.24 2:10
User Journal

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).

Read More 0 comments

+ -

  Comment: Re:Weighing Options (Score 1) on 2009.12.17 12:54

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.

Read More 20 comments
Comments: 20
+ -

  Comment: Re:Agreed (Score 1) on 2009.12.04 15:20

by perigrin on 2009.12.04 15:20 (#71317)
Attached to: Pitfalls in Converting Base Classes to Roles

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.

Read More 6 comments
Comments: 6
+ -

  Comment: Obviously Python is Dead (Score 1) on 2009.11.27 16:41

by perigrin on 2009.11.27 16:41 (#71256)
Attached to: Debian testing python version

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

Read More 6 comments
Comments: 6
+ -

  Journal: Perl Oasis 2010: Discount Hotel Rates End on 2009.11.24 20:48

Journal by perigrin on 2009.11.24 20:48
User Journal

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!

Read More 0 comments

+ -

  Comment: Re:Perhaps you've chosen a bad example... (Score 1) on 2009.11.19 2:17

by perigrin on 2009.11.19 2:17 (#71167)
Attached to: The unfortunate demise of the plan
Which is why I've happily moved to done_testing for future code.
Read More 25 comments
Comments: 25
+ -

  Comment: Perhaps you've chosen a bad example... (Score 1) on 2009.11.18 21:20

by perigrin on 2009.11.18 21:20 (#71164)
Attached to: The unfortunate demise of the plan

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.

Read More 25 comments
Comments: 25
+ -

  Comment: Re:Here we go again ... (Score 1) on 2009.10.14 14:49

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

Read More 20 comments
Comments: 20
+ -

  Comment: Re:Here we go again ... (Score 1) on 2009.10.14 13:17

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.

Read More 20 comments
Comments: 20