Nathan Wiger <[EMAIL PROTECTED]> writes:
> > * 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.
Good point
> > * 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'" ?
Ah, no. I wanted to draw a distinction between being strict about a
package properly implementing an interface and to use
C<use strict 'interfaces'> in client code to tell the compiler to
throw an error if I try to use a method that isn't declared for that
interface.
