Nathan Wiger <[EMAIL PROTECTED]> writes:
> By specifying "use interface" explicitly, you can make sure that your
> class follows the interface spec. Otherwise, you rely on other classes
> in the hierarchy above you doing so, and then you indirectly inheriting
> from that interface. So "use interface" is really the only way you can
> make sure somebody else didn't screw up. ;-) On large projects I think
> this would be an essential safety check, just like "use strict".
>
> -Nate
>
> package Pet : interface;
>
> sub isborn (@);
> sub scratches ($\@;@);
> sub annoys (\@);
> sub costsmoney ($$$$$$$$);
> sub poopsonfurniture ($);
Whoa Nellie. When did we get prototyping for methods. (Not that I'm
objecting, I think strict interfaces might actually make this
possible. The wisdom of it is left as an exercise...)
> package Cat;
>
> use interface 'Pet';
>
> sub isborn {
> bless { @_ }, self; # ;-)
> }
> sub scratches ($\@;@) {
> ...
> }
> sub annoys (\@) {
> ...
> }
> sub costsmoney ($$$$$$$$) {
> ...
> }
> sub poopsonfurniture ($) {
> ...
> }
>
>
> package Doggie;
>
> sub isborn {
> bless { @_ }, self; # ;-)
> }
> sub scratches ($\@;@) {
> ...
> }
>
>
> package Doggie::Cute;
>
> use base 'Doggie';
> use interface 'Pet';
>
> # Our base class is 'Doggie', which does not use the 'Pet'
> # interface (perhaps unbeknownst to us!). Nonetheless, we use
> # the 'Pet' interface to make sure that our class is implemented
> # correctly.
>
> # code would follow...
This could still be C<use base 'Pet'> and it would work you know. The
reasoning behind seperating C<use base> and C<use interface> (for me)
is simply because of the mnemonic assistance to the programmer.
interface.pm could easily be a duplicate of base.pm with the added
restriction that that the package so included *must* be an interface.
I'm not irrevocably tied to it...
--
Piers
