Slash Boxes
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 ]

TheNomad (7014)

  (email not shown publicly)

Journal of TheNomad (7014)

Sunday January 25, 2009
11:37 AM

Is Moose a fad?

Is Moose just a fad? Will it go the way of so many cool ideas in programming?

The answer to this question is important, because if it is a fad, I don't really want to create a dependency on it.

It's object introspection is extremely good, though.

Tuesday September 30, 2008
05:03 PM

Is Object::InsideOut broken?

Or is it Test::MockObject? Or UNIVERSAL::can that's broken?

This is something that has been exercising my mind recently, and I've decided that it's Object::InsideOut. (Yeah, go on flame me!).

If you use both Test::MockObject and Object::InsideOut in your project, you'll find you get lots of 'UNIVERSAL::can called as function not as method' warnings.

These warnings are generated by UNIVERSAL::can, which is pulled in by Test::MockObject.

Object::InsideOut grabs a code ref to UNIVERSAL::can:

$GBL{'can'} = \&UNIVERSAL::can

and then calls it:

$code = $$GBL{'can'}->($thing, $method);

Naturally, a warning ensues. I've managed to suppress the warning using the modules in this order at the head of the script:

use Object::InsideOut (); use UNIVERSAL::isa;

I just wish these two modules would play together nicely.

Sunday December 10, 2006
04:27 AM

Functional vs. OO

Since Joel Spolsky ranted about how few of his job applicants understand functional programming, it has become trendy (for some) to disparage object-oriented design. In the last few months, many perl afficionados, have rushed out to buy Higher Order Perl. This is a good thing, because re-thinking the need for OO is probably long overdue.

In OO design, all problems become problems of dealing with data. This works well when you really are dealing with data, say when you are pulling stuff out of a database and need to do something with the data. You design procedures 'aka methods' that work on this data transforming into other data.

For many tasks though, creating classes for everything, just creates an ugly, clunky design that is difficult to understand and a nightmare to maintain. So if, for example, I have a stream of characters that I need to transform into other characters. An OO approach would probably to create some sort of filter pattern. However, I'd suggest that a functional approach makes much more sense here and enables the problem to be broken down into simple actions so that small changes can easily be made to the system.

In this paper, the authors suggest a 'visitor' pattern to deal with a situation in an OO system where certain aspects are better dealt with in a functional way. To do this they create a 'processor' class, that behaves like a pure function.

The problem is that a 'processor' class is not in the spirit of OO. OO is about data. A class that doesn't contain any data, isn't really a class. It's a function. It means this aspect should be implemented 'functionally' rather than as 'OO'.

I'll probably get into trouble for say this. But the solution is ugly. OK, if you have to use OO then you're stuck with something like it. But if, you find you're creating classes just to transform objects of another class into objects of yet some other class, your design needs a rethink. IMHO, anyway.

Fortunately, in perl, it's fairly easy to combine both OO and functional approaches. The danger of the Perl freedom is that you end up with a mess, but done right, it should mean the best of all worlds.

Wednesday December 06, 2006
07:21 AM

Thinking about Accessors

I've been trying to maintain some legacy code that badly needs updating. One of the main sins committed in this code is direct object access, so $obj->{attribute} = 'value', rather than $obj->set_attribute('value');

To fix this, I need to choose a way to implement accessors. There are a few problems. Firstly, the 'perl' way of doing this seems to be a moving target. A few years ago, people used Class::MethodMaker, but the essential (in my opinion) 'new_with_init' option has gone. Now, people seem to be choosing either Class::Accessor. Of course, what's really trendy now is inside-out objects, and the module of choice (because it's mod_perl compatible) is Object::InsideOut.

I like Object::InsideOut. I like the interface. The problem is, because I'm using legacy code, I will need to assume the objects are blessed hashes for some time yet. Object::InsideOut wants the objects to be blessed scalars and croaks if they are anything else.

Class::Accessor's new method at least returns a hash. At the moment it's probably what I'll have to use. But it doesn't automatically sanity check. For example:

package GoodbyeThere;
use base 'Class::Accessor';
__PACKAGE__->mk_accessor s(qw/a b c/);

use strict;
use warnings;

sub do_stuff {
    my $self=shift;

    print "Output " . $self->get_a . $self->get_b. $self->get_c . "\n\n";


If you go:

perl -MGoodbyeThere -e '$h = GoodbyeThere->new({a => 1}); print "$h\n";$h->do_stuff'

The output is:

Output 1sssstttt

So far so good. But if you go:

perl -MGoodbyeThere -e '$h = GoodbyeThere->new({a => 1, query => 9}); print "$h\n";$h->do_stuff; print $h->{query}'

The output is:

Output 1sssstttt


See 'query' is still there. It would be better if it just threw it away. Which brings me to another point. With Class::Accessor, 'super' doesn't work as you might expect, so you need to write an accessor that sanity checks the input hash. I suppose there are worse things in life though...

Thursday June 29, 2006
08:56 AM

Odd inheritance behaviour

I've got an application where I have an abstract class A, B inherits from A, and C inherits from B. Class P has-a C.

Class A uses 'base' Class::Accessor::Fast to create accessors. All classes A, B and C do __PACKAGE__->mk_accessors, to make their accessors.

The test suite ran fine over classes A, B and C. However, when I came to run the tests for P, perl would complain 'can't find package method mk_accessors in class C'.

If I added 'use base 'Class::Accessor' to C, the tests would run fine. But this violated the principle that C should only inherit from B.

I guessed that somehow at compile-time perl wasn't running all the way up the class hierarchy when importing package C. I figured that delaying the import until run-time would fix this problem.

I changed 'use C' to 'require C' and the problem was solved, with the tests for class P running fine.

But the question remains, why is perl (5.8.8) not running all the way up the class hierarchy when it imports classes? Or is it something to do with the implementation of Class::Accessor::Fast?

Tuesday June 20, 2006
08:20 AM

Factories and Interfaces

Recently, needing to implement a factory pattern, I started using Class::Factory. It is a nice, easy-to-use base class for factory classes.

But what of the objects produced by my new, nice and shiny factory class, what are they like?

This is important because, if I am going to use a factory, then I need to know that objects produced by it respond to methods in a predictable way. They need the same, or almost the same, interface.

But of course, it's my factory class, and they are my objects, so I will write them all so that they conform to the interface.

The question is, is that enough? Should the factory classes check that any classes registered with them conform to the required interface?

And if I think I need this, should I do it with Class::Roles?

Monday June 19, 2006
12:34 PM

First journal entry and accessors

I finally registered on this site after looking for some ideas about how to automagically generate accessors. I had spent a whole day trying to get Class::MakeMethods do what it is supposed to do, especially in relation to arrays.

See perl doesn't have a standard way of dealing with accessors and I've never liked the common $foo->bar, $foo->bar('some value') type of accessors. I like "Afforability Accessors", so $foo->get_bar and $foo->set_bar('some value'). I was encouraged by Damian Conway's view that best practice is to use get_ and set_. Yippee!

So I gave up on Class::MakeMethods and decided to play with Class::Accessor. Wow! What a module! It is simple and it does what it says on the package. It is even easy to change the way that 'get' and 'set' work.

Which brings me to another point. In perl people write setters that return the value being set. Surely, it would be better to return the object, because that way it is easy to chain accessors.