princepawn has asked for the wisdom of the Perl Monks concerning the following question:

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.


Carter's compass: I know I'm on the right track when by deleting something, I'm adding functionality

Replies are listed 'Best First'.
Re: TIoCC :: DRYing the code
by jdporter (Paladin) on May 14, 2007 at 19:01 UTC

    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.

    A word spoken in Mind will reach its own level, in the objective world, by its own weight
Re: TIoCC :: DRYing the code
by ysth (Canon) on May 14, 2007 at 19:18 UTC
    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}).

Re: TIoCC :: DRYing the code
by Anonymous Monk on May 14, 2007 at 04:56 UTC
    Feeling bored huh? Recognize!