Re^2: From test harness to CPAN

[dwm042]

Grandfather,

There are some clever ideas in your post and I buy the idea that an object would make things easier. In a PDL implementation there will be a temptation to add features, because once you do the work of dataLoad, you'll want to have access to "more stuff". That's item one.

Item two is I'm testing your idea and the moment I start using the "pdl" command, the Perl interpreter doesn't appear to take well to the 'load it if we need it' idea.

I'm thinking two objects, a simpler one for non-PDL use and a more complicated one (that could do more kinds of rankings) for PDL use. But those are my current thoughts.

Using Sport as a base (the singular word as opposed to plural) is interesting as then people could write analysis objects for a particular sport.. Sport::Cricket or Sport::Baseball, etc.

David.

[GrandFather]

Most likely the 'load it if we need it' failed for a second object because PDL was already loaded. I was thinking more in terms of "use it if it's available" in any case. The following code implements that:

use strict;
use warnings;

package TestPDL;

my $PDLLoaded = eval {
    require 'PDL.pm';
    PDL->import ();
    1;
};


sub new {
    my ($class, %params) = @_;

    $params{havePDL} = $PDLLoaded;
    return bless \%params, $class;
}


package main;

my $obj  = TestPDL->new ();
my $obj2 = TestPDL->new ();

print $obj2->{havePDL}
    ? "Have PDL available"
    : "PDL not present or object create failed";

I'd write one basic object that does common stuff then derive from that to specialise for additional capabilities. Following that thought, I'd arrange the name space as Sport::Analytics::SRS for the basic module then Sport::Analytics::SRS::Cricket for the Cricket specialisation.

This technique allows a PDL only implementation for tricky or computationally expensive stuff with a pure Perl implementation provided either in the module or in a derived class at some point in the future if there is a need for it.