Re: RFC 265 (v1) Interface polymorphism considered lovely

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