Abstract Packages

Here's a little something I toss into packages that should be subclassed. I do something similar for "virtual" functions, too. -v

    sub new {
        my $this = shift;
        my $class = ref($this) || $this;



    # This part prevents a user from creating an
    # instance of the package, but still permits
    # subclasses to call the parent's new().

        my (undef, $filename, $line) = caller;
        $filename =~ s/^.*\///;
        die "Abstract class $class must " .
            "be subclassed at $filename " .
            "line $line.\n"
            if $class =~ /^Processor$/;



        bless $self, $class;
        return $self;
[download]

The subclassed code's new looks like this:

sub new {
  my $this = shift;
  my $class = ref($this) || $this;
  my $self = $this->SUPER::new(@_);
  bless $self, $class;
  return $self;
}
[download]

Comment on Abstract Packages Select or Download Code

Replies are listed 'Best First'.
Re: Abstract Packages by japhy (Canon) on Aug 04, 2004 at 13:27 UTC
I'll give you merlyn's "don't do `my $class = ref($obj) \|\| $obj`" advice. Don't do it. When I need abstract methods, I usually do: `sub some_abstract_method { __abstract($_[0], caller); # ... } sub __abstract { my ($thing, $pkg, $file, $line) = @_; return if $thing ne __PACKAGE__; my $func = (caller 1)[3]; die "$func is abstract; in $file line $line\n"; }` [download] Same general principle, but I think it's a little cleaner. _____________________________________________________ Jeff `japhy` Pinyan, P.L., P.M., P.O.D, X.S.: Perl, regex, and `perl` hacker How can we ever be the sold short or the cheated, we who for every service have long ago been overpaid? ~~ Meister Eckhart	[reply] [d/l] [select]
Re^2: Abstract Packages by Velaki (Chaplain) on Aug 05, 2004 at 11:47 UTC
For abstract methods, that's practically the same as the code I use. The code I posted was for abstract classes, although I could see how you could always make the constructor abstract, and handle it from there. -v "Perl. There is no substitute."	[reply]
Re: Abstract Packages by hv (Prior) on Aug 04, 2004 at 14:19 UTC
Any particular reason you disallow both "Processor" and "Processor\n" as package names? I'd have been inclined to use an nice simple string compare instead of a regexp: `... if $class eq 'Processor';` [download] For more generality, I'd take advantage of the builtin symbol to make the same check work everywhere: `... if $class eq __PACKAGE__;` [download] (And, for the record, I have no problem with `ref($this) \|\| $this`.) Hugo	[reply] [d/l] [select]
Re^2: Abstract Packages by Ovid (Cardinal) on Aug 04, 2004 at 16:55 UTC
I've no problem with `ref $this \|\| $this` either, but there is absolutely no consensus in the Perl community regarding expected behavior when a constructor is called on an instance. (Maybe nethack should get launched.) That's the real problem with that construct. If the programmer puts it in the code, he or she should understand why it's being put in and document it. Otherwise, why bother writing it? Update: Now that I think about it, using this without documentation is even more problematic with an abstract base class. If I'm subclassing a module, I'm tightly coupling my subclasses behavior with that of my superclass(es). It's even more important that I understand the behavior of those classes with such coupling, therefore I would be even more inclined to ding someone for `ref $proto \|\| $proto` unless that person had clear documentation. If it's not documented, it's not a contract with those who use the class and, as such, cannot be defined behavior. Using undefined behavior is a Bad Thing and subclasses should be especially vigilant not to do this (not that I would excuse this in everyday code, either.) Cheers, Ovid New address of my CGI Course.	[reply]
Re^2: Abstract Packages by Velaki (Chaplain) on Aug 05, 2004 at 11:43 UTC
When I was using __PACKAGE__ it was evaluating to something other than 'Processor', and thus would still allow instantiation of the abstract base class. -v "Perl. There is no substitute."	[reply]


No such thing as a small change
	PerlMonks