Test bed example: How to acheive plug-in for complex object?

John M. Dlugosz has asked for the wisdom of the Perl Monks concerning the following question:

This is a more specific approach to something I was asking earlier, on how to extend classes in Moose. I've had quite a bit of discussion here and on #moose IRC, and have done a lot of reading too.

Here is a sample class to be used to illustrate the possible solutions and show the specific issues of the problem:

use 5.10.1;
use utf8;

package C;   # main class with user-facing API
use Moose;
use MooseX::Method::Signatures;

method foo (Str $x)
 {
 say "Called original foo($x).";
 }

 
method build_c2
 {
 return C::C2->new;
 }
 
has c2 => (
   is => 'rw',
   handles => [ 'bar' ],
   builder => 'build_c2',
   lazy => 1
   );


method build_c3
 {
 return C::C3->new;
 }
 
has c3 => (
   is => 'rw',
   handles => [ 'baz' ],
   builder => 'build_c3',
   lazy => 1
   );

   
# ==================

package C::C2;  # a helper class
use Moose;
use MooseX::Method::Signatures;

method bar (Str $x)
 {
 say "Called original bar($x).";
 }
 
# ==================

package C::C3;  # a helper class
use Moose;
use MooseX::Method::Signatures;

method baz (Str $x)
 {
 say "Called original baz($x).";
 }
 
# ==================

package main;
 
my $c= C->new;
 
$c->foo (1);
$c->bar (2);
$c->baz (3);
[download]

Basically, a "complex" class as I dubbed it has its work factored out into various helper objects. Instances of several classes collaborate under the hood of the main object. Each class solves a well-defined part of the whole problem, and this is "good" and better code than throwing everything into one object, mingling the state data and methods in one big pot.

Now, lets say we have extensions to C. In order to work, an extension needs to hook the methods foo, bar, and baz. By "hook" I mean it can override or use before/after/around modifiers of some kind.

As you can see, the methods are spread out over three different classes (albeit in a simple way). I've also made the attributes "rw' for ease in solving the problem.

Approach 1: run-time patching (traits)

A call to install an extension can apply a run-time role to $c, and also apply roles to $c->c2 and $c->c3. But that is evil "run time" patching...

Approach 2: apply before creating

Using the proper pedigreed MooseX::Traits and calling $c= C->with_traits(qw/ext1 ext2/)->new will apply the role ext1 and ext2 to C, and then call new. But that only fixes foo. How does it make C-with-roles apply the roles to C2 and C3 as well? For a single extension, it can override the builders. That's why this example shows two roles: they have to play together. Only after all roles are applied can it know what to create.

How would you do that?

Comment on Test bed example: How to acheive plug-in for complex object? Select or Download Code

Replies are listed 'Best First'.
Re: Test bed example: How to acheive plug-in for complex object? by Corion (Patriarch) on May 01, 2011 at 19:28 UTC
I would allow the user to specify or pass the delegating classes or objects in the constructor for C. Basically, I'd change the interface to `my $c = C::Enhanced->new( c1 => C1::Enhanced->new(), c2 => 'C::C2::Better', # will implicitly call C::C2::Better->new() );` [download] It seems to me that C only specifies the workflow while C1, C2 etc. supply the worker implementation. I really wouldn't want to write new C classes just to change the implementation of the workers when the workflow itself remains the same. I would want to be able to load such a workflow configuration from a configuration file, which to me means that it should be specified as parameters to C, not as subclasses of C.	[reply] [d/l]
Re^2: Test bed example: How to acheive plug-in for complex object? by John M. Dlugosz (Monsignor) on May 02, 2011 at 01:22 UTC
That's a better idea in the case where the inner classes represent things in the user's problem domain that can have different concrete classes. For example, different database back-ends, different template output renderers, and so on. In the case I'm thinking about, those are not in the user's space. The "real" program I'm experimenting on does conversion of Wiki Creole to xhtml. The heavy-lifting classes inside would seem logical if explained, and concern parsing and processing details. But the user doesn't care, typically. The user does care about "extensions", such as "auto-generate table of contents", or one to provide for an Anchor/Reference syntax, or perhaps to add totally new grammar constructs that generate whatever xhtml, added into the mix. The user should simply say "I want the Creole class with this that and the other stuff added in". Using the AutoTOC extension shouldn't come with instructions to tell the user, "after you use this Role, on the resulting object be sure to construct it with c1 and c2 parameters that also have the corresponding roles added to them too". Using the M role on C should, by itself, also ensure that the M::C2 role is applied to the C2 and the M::C3 role is applied to C3, when the class constructs them. (Another thing I didn't mention earlier: the extensions should be singular and idempotent. AutoTOC itself pulls in Anchor, and it shouldn't matter if you specify Anchor yourself too.)	[reply]