No. Next question.

Seriously, CGI.pm is a terrible example of interface design. The OO interface is constantly breaking because of the need to support the non-OO one, which relies on lots of globals and requires crazy stunts in long-running environments like mod_perl and FastCGI.

Here are some reasons to avoid mxing:

• Inevitably means more code to maintain, test, and change. Your code would require changes in multiple places if you modify the parameters a function takes.
• Ruins OO features like inheritance.
• You didn't actually do this in your example, but having some subs that are called as functions and some that are called as class methods in the same package inevitably leads to confusion and bugs caused by mistakenly calling one the wrong way.

In Foo.pm:

#!/usr/bin/perl
use strict;
use warnings;

package Foo;

sub new {
    my $class = shift;
    bless { name => 'foo' }, ref($class)||$class;
}

sub bar {
    my $ref = ref $_[0];
    if ($ref eq __PACKAGE__) {
        ## OO method call
        oo_bar (@_);
    }
    elsif ($ref eq 'HASH') {
        ## imperative subroutine call with hashref as first element
        im_bar (@_);
    }
}

sub oo_bar {
    my $self = shift;
    print "oo_bar got object named ", $self->{name}, "\n";
}

sub im_bar {
    my $hr = shift;
    print "im_bar got hashref with name ", $hr->{name}, "\n";
}

1;
[download]

#!/usr/bin/perl
use strict;
use warnings;

use Foo;

my $hr = { name => 'hashref' };
my $obj = new Foo;

## OO method call
$obj->bar;

## imperative call, but since $obj is a blessed object,
## this is equivalent to the OO call
Foo::bar($obj);    

## imperative call        
Foo::bar($hr);
[download]

I would consider it good programming practice to put maximum flexibility into how your subroutines may be called, as long as this flexibility doesn't introduce too much complexity on the backend. That's your call.

There are some gotchas here.

bless { name => 'foo' }, ref($class)||$class;

The ref dance is completely unnecessary. Unless you're implementing a prototype-based OO system (and the rest of the constructor suggests that you're not), drop it.

    my $ref = ref $_[0];
    if ($ref eq __PACKAGE__) {
[download]

This just broke inheritance. If you really need to do this check, use Scalar::Util's blessed() or reftype().

my $obj = new Foo;

This syntax introduces weird parser ambiguities that often depend on the order of compilation. Stick with Foo->new().

Foo::bar($obj);

This breaks inheritance.

... you can make the ref $_[0] business a little cleaner with use UNIVERSAL 'isa'...

That will break delegation and cognates and has the possibility of breaking inheritance. It may break overloading as well.

my $obj = new Foo;

This syntax introduces weird parser ambiguities that often depend on the order of compilation. Stick with Foo->new().

According to the Camel Book beside me, method invocation using the METHOD CLASS_OR_INSTANCE LIST form is exactly equivalent to CLASS_OR_INSTANCE->METHOD (LIST) form.

A typical test for me is something like:

 {
   my $test_name = "rect_probe";
   my $bf = Image::BoxFinder->new();
   my $spot = $bf->rect_probe;
   is_deeply( $spot, [ 0, 0 ], "Testing $test_name: found rectangle");
}
[download]

On the subject of mixing and matching methods and proceedures in one module: this makes some people queasy, and I have mild reservations about it myself, though they're only mild.

On the subject of modules with both an object and a proceedural interface, myself I think they're over-kill. Remember: if you put in two totally different interfaces, you're going to have to document both of them.

-David

I'd avoid mixing the two models.

If I really needed an imperative interface and an OO interface, I'd be inclined to make an imperative wrapper for an OO library. I'm not 100% sure about how I'd handle the details. I think you'd have to do some autoloading of subroutines.

For example, if I call ImpWrapper::foo(), then ImpWrapper::AUTOLOAD would need to check to see if its global object has a method foo(). If so, we would create ImpWrapper::foo() and have it delegate to  $iw_global_obj->foo().

My AUTOLOAD-fu is not really that good, so to be sure of this approach, I'd have to spend more time than I have investigating it. But it seems like it should work pretty well, as long as you don't do anything crazy, like reblessing your wrapper's object into a different class.

I can imagine a general ImpWrap module that allows you to do something like:

package Imperative::TheObject;
use ImpWrap TheObject => ( 
      name    => foo, 
      address => '123 A Street',
      foo     => 'bar',
);
[download]

Then ImpWrap would create a TheObject object, and put it into the Imperative::TheObject namespace. ImpWrap would also insert an appropriate AUTOLOAD routine.

If I ever thought I might need such a thing, it might be an interesting project.

Here's a first pass at what I was talking about above:

use strict;
use warnings;

package ImpWrap;

sub import {
    my $this  = shift;
    my $class  = shift;
    my $method = shift;


    my $caller = (caller)[0];

    warn "Importing $class/$method from $caller\n";

    my $obj = $class->$method(@_);

    {   no strict 'refs';
    
        my $autoload = sub { 
            our $AUTOLOAD;

            my ($al_method) = $AUTOLOAD =~ /::([^:]*)$/g;

            if ( $class->can( $al_method ) ) {

                *{ $AUTOLOAD } =  sub { 
                    $obj->$al_method( @_ ); 
                };

                goto &{$AUTOLOAD};

            }
            else {
                require Carp;
                Carp::croak "Undefined subroutine $AUTOLOAD";
            }
        };

        # Insert AUTOLOAD function;
        warn "Setting autoload\n";

        *{ "$caller\::AUTOLOAD" } = $autoload;
    }

}

package Fuz;
use Data::Dumper;

sub bizzle {
    my $self = shift;

    print "bizzle: $self\n";
    print Dumper $self;
}

sub new {
    my $class = shift;

    bless {@_}, $class;
}

package Foo;
our @ISA = ('Fuz');


package IW::Foo;

import ImpWrap 'Foo', 'new', (1..4);

package IW::Fuz;
import ImpWrap 'Fuz', 'new', (11..20);

package main;

IW::Foo::bizzle();
IW::Fuz::bizzle();

IW::Foo::Grazzle();
[download]

I'm sure there are lots of things this doesn't do quite right yet. I know it doesn't handle autoloads in the wrapped object class properly. Or inherited autoloads.

The main thing is that it seems to work for basic usage. I create an AUTOLOAD function for the wrapper package that is a closure around the wrapped object. As a result, any class methods will be called as instance methods. I could make it possible to define a list of class methods to call by name, methods to skip, and so forth, by adding appropriate argument handling to the import subroutine.

Anyhow, this is just a start. I'd like to get proper handling of AUTOLOADs in wrapped objects (with inheritance) and any other gotchas I can think of handled. Any suggestions are welcome.


TGI says moo

Just because it can be done doesn't mean it should be though!

I've recently adopted a coding style that results in code that can be executed both purely procedurally or in an object oriented fashion. I find that as long as I consistently stick to the style, my code is much more flexible for both internal and external use.

In a nutshell, I alwas add the line my( $self, %args ) = @_; *unless* it's an new *or* import. Then I substitute $self with $class.

The resulting subroutines end up looking like this:

sub do_something {
    my( $self, %args ) = @_;
    my( $scalar ) = $args{scalar}
        || eval { $self->{scalar} }
        || $self->SCALAR;
    my( @list ) = ( eval { @{ $args{list} } or 1 } )
        ? @{ $args{list} 
        : $self->LIST;
}
[download]

Then calling code can choose to pass in parameters it wishes to override, or define a subclass that overrides the defaults (such as SCALAR and LIST.)

This approach has worked well for me so far. It supports both OO and procedural. It doesn't break inheritance, in fact it uses inheritance to reduce the number of arguments necessary if changing the defaults makes sense.

If you don't need to store all the parameters why would you want to make it an object? And if you always need the parameters why would you want to make it functional?

I've never had that issue, but i've never had code that could go either way. If I did, then I think i would make it OO and then users who wanted to use it without storing parameters in the object could build an object with no parameters and call its methods passing all information.

my $house = new House(width=>100, height => 100);
$house->sweep;

# or

my $blank = new House;
$blank->sweep(width=>100, height => 100);

# or even

House->new->sweep(width=>100, height => 100);
[download]

Either way make sure that your new isn't an expensive method and it shouldn't matter alot.