[% setvar title Interface polymorphism considered lovely %]

This file is part of the Perl 6 Archive

Note: these documents may be out of date. Do not use as reference!

To see what is currently happening visit http://www.perl6.org/


Interface polymorphism considered lovely


  Maintainer: Piers Cawley <pdcawley@bofh.org.uk>
  Date: 20 Sep 2000
  Last Modified: 29 Sep 2000
  Mailing List: perl6-language-objects@perl.org
  Number: 265
  Version: 3
  Status: Frozen


Add a mechanism for declaring class interfaces with a further method for declaring that a class implements said interface. There should be (at least) runtime checking to ensure that a class actually *does* implement said interface, with an option to have compile time checks made.


Nothing has changed since version 2. There's still probably stuff that could use working on, but the deadline looms like a big loomy thing, so into the freezer it goes.





To (mis)quote Damian Conway "Inheritance polymorphism proliferates pretend classes".

The idea is that my Dog $spot will eventually give us some real performance gains, so more folks will want to use it. But this leads to a proliferation of 'ghost' base classes that are simply there to provide a handle for my Foo $bar optimization.

So, I propose that we move such classes sideways and make them into first class interfaces. By supporting interface polymorphism the way is opened for adding more stricture in projects that *need* it, as well as allowing for the possibility of compile time optimization for classes that use the interface structure.

<This needs some more fleshing out>


My current thought is that an interface file would look something like:

  interface Fetcher;

  sub fetch;

Note the new keyword, interface, this works just like package but with the restriction that it can only contain subroutine declarations.

A Class that implements the interface would then look like:

  package TrainedCat;

  use strict 'implementation';
  use strict;

  use base 'Cat';
  use interface 'Fetcher';

  sub fetch {
     my TrainedCat $self = shift;
     my $thing = shift;

     return $self->can_lift($thing) ? $thing : undef;

Note the use strict 'implementation', this declaration implies that interface conformance shall be checked at compile time. If the TrainedCat class doesn't implement the Fetcher interface in full then compilation shall fail. Without this stricture constraint the compiler shall throw a warning.

If an interface file contains anything but forward subroutine declarations the compiler shall throw an error.

[NOTE: What about interface inheritance hierarchies, thoughts please]

Of course, Perl being Perl and all lovely and dynamic, there's a good chance that some of the methods that implement the interface aren't actually compiled up at the end of the compilation phase. Therefore we have:

  package LazyDog;

  use strict 'implementation';
  use interface 'Fetcher';

  use deferred qw/fetch/;


  sub AUTOLOAD {
    *fetch=sub {...}; goto &fetch;

use deferred informs the compiler that the method will be available when it's needed, even if it isn't actually in the symbol table/class hierarchy just yet.

In client code, lexicals that are typed into interfaces only require that the objects assigned to them satisfy the interface. ie. They don't care about an objects class, they just care what it can do. (If only life were like that...)

  use strict 'interfaces';

  my Fetcher $x;
  my Dog $spot;
  my NetSnarfer $z;
  my $method = 'fetch';

  # Compile time stuff
  $x = $z;        # ok because $z can fetch
  $x = $spot;     # ok because $spot can fetch
  $x->fetch();    # ok because Fetcher->can('fetch');
  $x->bark();     # not ok because ! Fetcher->can('bark');
  # Runtime stuff
  $x->$method();  # ok because Fetcher->can('fetch');
  $x->$method();  # runtime error because ! Fetcher->can('bark')

Without the my strict 'interfaces' declaration, these errors get demoted to compile time warnings. Of course, without the stricture any compiler optimizations become somewhat tricky.

Another possible syntax

Nathan Torkington suggested another syntax:

  package Cat implements Pet;
  package Dog implements Pet;

Which is kind of neat.


Because the compiler will know about available methods for typed variables it may become possible to have Damian's named argument magic for method calls, though this is a tad scary to me...


I have some ideas about this, and I believe it may be possible to do a good chunk of the runtime/compile time behaviour in pure perl, but if we are to gain performance gains for more than just the programmer (though it's my contention that the potential time savings available to the programmer who's bug hunting are reason enough for this change) this stuff should be usable in core. And I know little of the core.

I've thought about this some more, using an interface should imply a check block along the lines of:

  package Dog;

      foreach my $interface (@IMPLEMENTS) {
          foreach my $method (keys %{$::{$interface}}) {
              die "Method $method not implemented" unless
                  implements::can_somehow('Dog', $method);

where implements::can_somehow is similar to UNIVERSAL::can but it walks the inheritance tree.


I'm not sure that there are any migration issues, what with this being a new bunch of syntax and all...


RFC 218: my Dog $spot is just an assertion

Some of the subsequent discussion of this RFC contains some discussion of adding interface polymorphism to perl.

RFC 193: Objects : Core support for method delegation

If a package delegates a bunch of its methods, the compile time checks should notice this and (possibly) count them as contributing to the implementation of the interface.


Java is one language that springs to mind that uses interface polymorphism. Don't let this put you off -- if we must steal something from Java let's steal something good.