Re: RFC 265 (v1) Interface polymorphism considered lovely

>         * The new C<interface> keyword would be unnecessary if *package
>           specifications* could take attributes:
> 
>                 interface Fetcher;
> 
>           would then become:
> 
>                 package Fetcher : interface;

I'm not sure about this - seems like we're squeezing a whole bunch of
stuff into "package" that's not a package.

If an interface can't have variables, real methods, or do anything, then
a separate keyword seems in order. Looking at this:

   interface Fetcher;

Makes it much more obvious "Ok, here's an interface, not a package. I
can't stick 'real stuff' in here". However, if we are going to
potentially add many more attributes, like

   package int : variable;    # custom var for "my int $x = 5";

then perhaps attributes are the way to go after all.

It should also be a compile-time error for an interface to contain
anything except sub definitions (and possibly constant variables). I
didn't see that mentioned, but I could have missed it.

>         * There's also no need to distinguish C<use base> and C<use interface>,

Again, I'm not sure. As the RFC shows, it's quite easy to imagine a
situation where you have a tangential interface specification that does
*not* serve as the inheritance point for your class:

   package TrainedCat;

   use strict 'implementation';
 
   use base 'Cat';
   use interface 'Fetcher';

I can see many potential uses for keeping interfaces and classes
separate.

Finally, maybe that should be "use strict 'interface'" ?

-Nate