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

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.

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

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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

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]