From: Stevan Little Date: Sun, 26 Feb 2006 19:47:30 +0000 (+0000) Subject: adding in the safe mixin stuff X-Git-Tag: 0_20~11 X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=d3cb0d4a108d86afe5ce6ccd03ceed2d26a7641e;p=gitmo%2FClass-MOP.git adding in the safe mixin stuff --- diff --git a/Build.PL b/Build.PL index 77fb9e4..93daac5 100644 --- a/Build.PL +++ b/Build.PL @@ -10,7 +10,6 @@ my $build = Module::Build->new( 'Sub::Name' => '0.02', 'Carp' => '0.01', 'B' => '0', - 'Clone' => '0.18', }, optional => { }, diff --git a/Changes b/Changes index 886eb4c..481881b 100644 --- a/Changes +++ b/Changes @@ -1,5 +1,12 @@ Revision history for Perl extension Class-MOP. +0.13 + - removed the dependency for Clone since + we no longer to deep-cloning by default. + + * Class::MOP::Class + - improved &get_package_variable + 0.12 Thurs. Feb 23, 2006 - reduced the dependency on B, no need to always have the latest diff --git a/README b/README index b053927..67318ec 100644 --- a/README +++ b/README @@ -1,4 +1,4 @@ -Class::MOP version 0.12 +Class::MOP version 0.13 =========================== See the individual module documentation for more information diff --git a/lib/Class/MOP.pm b/lib/Class/MOP.pm index c250d2a..7e228ae 100644 --- a/lib/Class/MOP.pm +++ b/lib/Class/MOP.pm @@ -11,7 +11,7 @@ use Class::MOP::Class; use Class::MOP::Attribute; use Class::MOP::Method; -our $VERSION = '0.12'; +our $VERSION = '0.13'; ## ---------------------------------------------------------------------------- ## Setting up our environment ... diff --git a/lib/Class/MOP/Class.pm b/lib/Class/MOP/Class.pm index 099e1fa..efdcab2 100644 --- a/lib/Class/MOP/Class.pm +++ b/lib/Class/MOP/Class.pm @@ -8,9 +8,8 @@ use Carp 'confess'; use Scalar::Util 'blessed', 'reftype'; use Sub::Name 'subname'; use B 'svref_2object'; -use Clone (); -our $VERSION = '0.05'; +our $VERSION = '0.06'; # Self-introspection diff --git a/lib/Class/MOP/SafeMixin.pm b/lib/Class/MOP/SafeMixin.pm new file mode 100644 index 0000000..dd1f186 --- /dev/null +++ b/lib/Class/MOP/SafeMixin.pm @@ -0,0 +1,132 @@ + +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 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, I +and I methods with which method conflicts can be resolved. + +A method, which would normally conflict, but which is labeled with +either a I, I or I 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, I and I 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 Estevan@iinteractive.comE + +=head1 COPYRIGHT AND LICENSE + +Copyright 2006 by Infinity Interactive, Inc. + +L + +This library is free software; you can redistribute it and/or modify +it under the same terms as Perl itself. + +=cut \ No newline at end of file