Re: RFC 265 (v1) Interface polymorphism considered lovely

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.