At 08:13 AM 9/15/00 +1100, Damian Conway wrote:
>Piers wrote:
>
>    > I'm kind of tempted to look at adding another pragma to go with 'use
>    > base' along the lines of:
>    >
>    >      use implements 'Interface';
>    >
>    > Which is almost entirely like C<use base 'Interface'> but with
>    > 'Interface' consisting of nothing but:
>    >
>    >
>    >      package Interface;
>    >
>    >      sub virtual_method;
>    >      sub virtual_method2 (#prototype);
>    >
>    >      ...
>    >
>    >      1;
>
>You and I must have been separated at birth, Piers.
>
>Here's what I wrote to Nat just yesterday:
>

<snip>


>         Interfaces might also act like pure abstract base classes when
>         inherited, so that:
>
>                 package Dog;
>                 use base 'Fetcher';
>
>         would cause a compile-time error if Dog failed to actually provide
>         a C<fetch> method.

I don't like that at all...

Currently, Object implementations can be changed at will at runtime.  In 
particular, it is possible to create new methods and change the class 
hierarchy at run time.

package TextFilter;
use CryptInterface;
@ISA = qw(CryptInterface);

sub AUTOLOAD {
   my $self = shift;
   ($name = $AUTOLOAD) =~ s/.*://;
   # Cryptography is very hairy and we don't want to load it if we don't
   # have to.
   if ($name = any(qw(setkey setcrypt encode decode)) {
      require Crypt;
      import Crypt;
      push @ISA,"Crypt";
      $self->$name(@_);  # I've not tried this, it may be wrong.
   }
}

I'd hate to have that break because TextFilter isn't derived from Crypt 
unless it needs to be.

I think calling a method declared in an inherited interface but not 
implemented would be a good reason to have a descriptive run-time error, like:

Method getkey in interface Crypt not implemented in TextFilter object at 
line....

Well, perhaps written better...

>If you'd like to run with it, be my guest (but check with Nat first, in
>case he wants it).
>
>Damian

Reply via email to