Re: RFC 254 (v2) Class Collections: Provide the ability to overload classes

Perl6 RFC Librarian <[email protected]> writes:

> This and other RFCs are available on the web at
>   http://dev.perl.org/rfc/
> 
> =head1 TITLE
> 
> Class Collections: Provide the ability to overload classes
> 
> =head1 VERSION
> 
>   Maintainer: Greg Williams <[email protected]>
>   Date: 17 Sep 2000
>   Last Modified: 1 Oct 2000
>   Mailing List: [email protected]
>   Number: 254
>   Version: 2
>   Status: Frozen
> 
> =head1 ABSTRACT
> 
> Currently, class methods can be overloaded through sub-classing. This
> functionality is perhaps the most compelling aspect object oriented
> programming offers.  This mechanism allows one to extend the functionality
> of pre-existing code without significant copying or rewriting.  However,
> there exists situations in which it is desirable not to extend methods, but
> entire classes.
> 
> It is proposed that classes be able to be grouped into collections.
> Collections would have the ability to inherit from other collections just
> as classes inherit from other classes.  A sub-collection would overload
> super-collection classes exactly like subclasses overload superclass
> methods.

Hmm... I'm really not keen on this idea. Not keen at all. And I can't
for the life of me see what's wrong with just making a factory method
(or factory class):

    package Forest;
  
    sub new {
        my $class = shift;
        my $location = shift;
        my $frog = FrogFactory->appropriate_frog($location);
        bless( { frog => $frog }, $class );
    }

    package FrogFactory;

    my %local_breed = (
        ...
        Nagano => 'Frog::Japanese',
        ...
    );

    sub appropriate_frog {
        shift;
        $local_breed{shift}->new();
    }

Or even simply:

    package Forest;
    
    sub new {
        my $class = shift;
        my Frog $local_frog_class = shift || 'Frog';
        my Frog $frog = $local_frog_class->new;
        bless({ frog => $frog }, $class);
    }

> I am unaware of any OO language that allows overloadable classes as
> described here, and have seen them described only once, but have run into
> many situations in which they would make sense.  I suggest this as a
> solution to the problem described here for perl 6.

As far as I can see, the standard technique for this is either to use
Factory methods and/or interface polymorphism. After all, the Forest
class doesn't care *what* class its Frog is in, so long as it croaks
like a Frog. So don't have the Forest instantiate its frog directly.
(Or if it does have it instantiate only a default frog but allow
client code to pass a different frog in)

> 
> =head1 IMPLEMENTATION
> 
> Let it be said that I am not an internals person, nor do I claim to know
> enough about the current or planned perl internals to comment on this
> authoritatively.  However, there are two areas of concern I am aware of to
> which an implementation of class collections must direct its attention:
> 
> =over 4
> 
> =item * Class Names Would No Longer Be Unique
> 
> A namespace alone would no longer reference a unique stash, as many stashes
> might contain code and data for one namespace (such as 'Frog').  Therefore,
> a namespace and collection name pair would be needed to specify a unique
> stash.

This would be nasty.

> =item * Method Lookup
> 
> Method lookups would need to examine the collection inheritance tree to
> determine which class (that is, in which collection) to dispatch method
> calls to.

So would this.

Seriously, the problem you refer to is already solved. Check out
Design Patterns for a whole host of ways of getting rid of 'tight'
coupling between classes.

-- 
Piers