But an abstract class gives the programmer a chance to inform the next programmer that some derived classes share a common interface, so that if a new derived class is added, the common methods are expected to be implemented. And, an abstract class can implement common behavior as well, even if it's never instantiated.

-- Randal L. Schwartz, Perl hacker

One thing that distinguishes an "abstract" class from a concrete one is that you shouldn't create instances the abstract class. There's no need for special syntax for this. You need merely do something like:

    package AbstactFoo;
    ...
    sub new {
        die "Don't create any Abstract Foos direct, fool!";
    }
[download]

   package AbstractFoo;
    ...
    sub new {
        my $package = shift;
        bless { @_ }, $package;
    }
    ...
    my $foo1 = new SubclassOfAbstractFoo(); # GOOD
    my $foo2 = new AbstractFoo();           # BAD
[download]

    package AbstractFoo;
    ...
    sub new {
        my $package = shift;
        die "Don't subclass AbstractFoo directly!"
           if $package eq "AbstractFoo";
        bless { @_ }, $package;
    }
[download]

(Bonus points to whoever sees a way to generalize this even further.)

    package AbstractFoo; 
   ... 
    sub new { 
        my $package = shift; 
        die "Don't subclass AbstractFoo directly!" 
           if $package eq "AbstractFoo"; 
        bless { @_ }, $package; 
    }

(Bonus points to whoever sees a way to generalize this even further.)

sub new {
  die "this is an abstract subclass" if $_[0] eq __PACKAGE__;
  shift->SUPER::new(@_);
}
[download]

-- Randal L. Schwartz, Perl hacker

Next time I'll limit the bonus points to Monks or below :)

The use of __PACKAGE__ was what I was looking for. I was thinking along the lines of

    package AbstractFoo;
    ...
    sub new {
        my $package = shift;
        die __PACKAGE __ . " is an abstract class"
            if $package eq __PACKAGE__;
        bless { @_ }, $package;
    }
[download]

merlyn and I had a back and forth in the CB about the difference between his solution and mine. I noted that his would fail if nobody in AbstractFoo's superclass chain implemented new. merlyn agreed, saying (and here I'll ask him to correct me if I get the details wrong) that this was correct behavior, given that there's no generic way to implement new. I granted that point, but cited the Smalltalk image as evidence that there were common patterns. That, in essense, is where we left the discussion.

And as with most other things related to OO Perl, you have to do it yourself :) I usually die with a helpful error message in abstract methods to inform the programmer that the method needs to be redefined.

/J

Ahhh, the BIFFwriter! And the irony: I started using Spreadsheet::WriteExcel just last week. Works like an absolute charm! Thanks John!

Jeff

R-R-R--R-R-R--R-R-R--R-R-R--R-R-R--
L-L--L-L--L-L--L-L--L-L--L-L--L-L--

"Abstract classes and Perl" just makes me chuckle. Like you said, abstract classes allow you to define an interface... And in Perl, that comes down to precisely "a few method names". Despite there being at least two implementations (metioned above by tilly) of abstract classes in Perl, I can't help but wonder whether the minimal value is worth the effort.

Sure, using an abstract class in Perl prevents you from completely forgetting to implement one of the methods. It doesn't require that you even come close to using the same interface in the methods that share a name, because Perl has no useful, built-in tools for defining interfaces (prototypes are built-in but not useful for defining an interface and there are some modules that help you define an interface but they aren't built-in).

Now, if your interface was defined via something like Class::Contract, then an abstract class might be a worthwhile thing.

I can't help but wonder whether the minimal value is worth the effort. Sure, using an abstract class in Perl prevents you from completely forgetting to implement one of the methods...

This, by itself, can be enough.

Take, for example, an online shop that sells several different types of items - each of which will be a class. It quite often makes sense here to ensure that each of these has all the methods that will be needed in the system to be able to buy the item - a title, price, SKU, whatever.

Yes, you could just add it to your standards that anyone adding a new class of item must add these, and ensure that your reviewers look for this. But if you have an abstract class that all of these use, with an array of necessary types that you just add to any time you need to insist on a new abstract class method, then you don't need to do this. You just wait for the @ISA line to blow up!

Tony

Just to butt my $0.02 in...

Doesn't perl provide one abstract class?
package ("class") UNIVERSAL? it provides a basic set of interfaces: can(), isa(), and VERSION().
Or am I confused (possible)?
_________________
madams@scc.net

              (__)
              (\/)
       /-------\/
      / | 666 ||
     *  ||----||
[download]

No, if UNIVERSAL were an abstract class, then the can() and isa() methods would be unimplemented (that is what makes a class abstract -- none of its methods are implemented, the class consists of only a interface definition and no implementation) and you would be required to implement them yourself in any class you build that inherits from UNIVERSAL (which would be all classes since all classes inherit from UNIVERSAL implicitly).

        - tye (but my friends call me "Tye")