adding in the safe mixin stuff

[gitmo/Class-MOP.git] / lib / Class / MOP / SafeMixin.pm

package Class::MOP::SafeMixin;

use strict;
use warnings;

our $VERSION = '0.01';

sub meta { 
    require Class::MOP::Class;
    Class::MOP::Class->initialize(blessed($_[0]) || $_[0]);
}

1;

__END__

=pod

=head1 NAME

Class::MOP::SafeMixin - A meta-object for safe mixin-style composition

=head1 SYNOPSIS

=head1 DESCRIPTION

This is a meta-object which provides B<safe> mixin-style composition 
of classes. The key word here is "safe" because we enforce a number 
of rules about mixing in which prevent some of the instability 
inherent in other mixin systems. However, it should be noted that we 
still allow you enough rope with which to shoot yourself in the foot 
if you so desire.

=over 4

=item *

In order to mix classes together, they must inherit from a common 
superclass. This assures at least some level of similarity between 
the classes being mixed together, which should results in a more 
stable end product.

The only exception to this rule is if the class being mixed in has 
no superclasses at all. In this case we assume the mixin is valid.

=item * 

Since we enforce a common ancestral relationship, we need to be 
mindful of method and attribute conflicts. The common ancestor 
increases the potential of method conflicts because it is common 
for subclasses to override their parents methods. However, it is 
less common for attributes to be overriden. The way these are  
resolved is to use a Trait/Role-style conflict mechanism.

If two classes are mixed together, any method or attribute conflicts 
will result in a failure of the mixin and a fatal exception. It is 
not possible to resolve a method or attribute conflict dynamically. 
This is because to do so would open the possibility of breaking 
classes in very subtle and dangerous ways, particularly in the area 
of method interdependencies. The amount of implementation knowledge 
which would need to be known by the mixee would (IMO) increase the 
complexity of the feature exponentially for each class mixed in.

However fear not, there is a solution (see below) ...

=item *

Safe mixin's offer the possibility of CLOS style I<before>, I<after> 
and I<around> methods with which method conflicts can be resolved. 

A method, which would normally conflict, but which is labeled with 
either a I<before>, I<after> or I<around> attribute, will instead be 
combined with the original method in the way implied by the attribute.

The result of this is a generalized event-handling system for classes. 
Which can be used to create things more specialized, such as plugins 
and decorators.

=back

=head2 What kinda crack are you on ?!?!?!?

This approach may seem crazy, but I am fairly confident that it will 
work, and that it will not tie your hands unnessecarily. All these 
features have been used with certain degrees of success in the object 
systems of other languages, but none (IMO) provided a complete 
solution.

In CLOS, I<before>, I<after> and I<around> methods provide a high 
degree of flexibility for adding behavior to methods, but do not address 
any concerns regarding classes since in CLOS, classes and methods are 
seperate components of the system.

In Scala, mixins are restricted by their ancestral relationships, which 
results in a need to have seperate "traits" to get around this restriction. 
In addition, Scala does not seem to have any means of method conflict 
resolution for mixins (at least not that I can find).

In Perl 6, the role system forces manual disambiguation which (as 
mentioned above) can cause issues with method interdependecies when 
composing roles together. This problem will grow exponentially in one 
direction with each role composed and in the other direction with the 
number of roles that role itself is composed of. The result is that the 
complexity of the system becomes unmanagable for all but very simple or
very shallow roles. Now, this is not to say that roles are unusable, in 
fact, this feature (IMO) promotes good useage of roles by keeping them 
both small and simple. But, the same behaviors cannot be applied to 
class mixins without hitting these barriers all too quickly.

The same too can be said of the original Triats system, with it's 
features for aliasing and exclusion of methods. 

So after close study of these systems, and in some cases actually 
implementing said systems, I have come to the see that each on it's 
own is not robust enough and that combining the best parts of each 
gives us (what I hope is) a better, safer and saner system.

=head1 AUTHOR

Stevan Little E<lt>stevan@iinteractive.comE<gt>

=head1 COPYRIGHT AND LICENSE

Copyright 2006 by Infinity Interactive, Inc.

L<http://www.iinteractive.com>

This library is free software; you can redistribute it and/or modify
it under the same terms as Perl itself. 

=cut