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
