TIoCC :: DRYing the code

[princepawn]

Continuing my foray through Class::Component, we see in the source code (here for your reference) we see on lines 12-17 this:

for my $name (qw/ config components plugins methods hooks /) {
    my $method = "class_component_$name";
    no strict 'refs';
    *{__PACKAGE__."::$method"} = sub { shift->{"_$method"} };
}

but then in the constructor starting on line 156 we see this:

sub new {
    my($class, $c, $args) = @_;
    $args ||= {};

    my $self = bless {
        %{ $args },
        _class_component_plugins         => [],
        _class_component_components      => $default_components->{$c},
        _class_component_methods         => {},
        _class_component_hooks           => {},
        _class_component_config          => $args->{config} || {},
        _class_component_default_plugins => $default_plugins->{$c},
    }, $c;

    $self->load_plugins(@{ $default_plugins->{$c} }, @{ $args->{load_p
+lugins} || [] });

    $self;
}

And this is fine until you apply the DRY principle. Correct me if I'm wrong, but DRYer code would have applied a recognizer to the hash of $self like this:

my @class_component = grep /^class_component_/ keys %$self ;

and then the constructor should have initialized these components like so:

build_accessors(@class_component) unless $build_accessors++;

WHY?

We do not want to do things twice. Thus, we do not want to list the things for access at the top and then build the accessors later.

[jdporter]

DRY:

"In some small-scale contexts, the effort required to design around DRY may be far greater than the effort to maintain two separate copies of the data."

I submit that this may be just such a context.

[ysth]

Having class initialization in the constructor bothers me. Also, there isn't a class_component_default_plugins accesssor constructed by the existing code. Presumably that's not a bug, but even if it is, there certainly exists the possibility that a C::C subclass might make _class_component_* attributes for which there should be no accessor (or only a customized one), and C::C itself has no way of knowing that.

If you really want to unDRY, I'd suggest going the other way: having the explicit list in @class_component up top and sub new use that (perhaps with $default_foo becoming $default{foo}).

[Anonymous Monk]

Feeling bored huh? Recognize!