> > 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.
No, it couldn't - notice that Doggie does not inherit from Pet. Unless
there's something about OO inheritance that I'm really missing...
> 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.
Yes, and I think that's a very worthwhile distinction. It also allows
you to mandate that you use multiple interfaces and a different base to
boot. This is a stretch but you should get the idea:
package Solaris::Devices::Ethernet::GigEther;
use base 'Solaris::Devices::Ethernet';
use interface 'Solaris::Kernel::Kmem';
use interface 'Solaris::Devices::Devtree';
But maybe I'm barkings up a different tree from you. But it seems that
interfaces don't have to be constrained to just stub base class
definitions. Instead, they can serve as specifications for class
interaction as well as class implementation. If we keep "use interface"
and "use base" separate then this becomes trivial to do (compile-time
checks for proper method declarations/etc).
-Nate
