Nathan Wiger <[EMAIL PROTECTED]> writes:
> > > 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...
You can use C<use base> more than once you know? Or you can do:
use base qw/Doggie Pet/;
If we introduce the C<interface> syntax instead of just using
C<package> then the compiler will no that Doggie is a Class and Pet is
an interface. Personally I think there's room for confusion there and
I'd rather don belt *and* braces, but that doesn't mean we *can't*
give people enough rope.
> > 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.
Hard to tell. You seem to be assuming that I know rather more about
the way Solaris handles devices than I actually do, which makes it
kind of hard to know what you're tilting at here.
> 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.
Er... if you mean what I think you mean then that's kind of the point.
> If we keep "use interface" and "use base" separate then this becomes
> trivial to do (compile-time checks for proper method
> declarations/etc).
Damian's point was that, if we introduce an C<interface> keyword
rather than overloading C<package> then the C<base> pragmatic module
can work all that out by looking at whether an identifier was declared
as a package or as an interface. And he's right, technically. But
there's a 'social' implication we need to take into account.
I think I've just started to repeat myself...
--
Piers
