> * 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
