in reply to converting to a sub-class

I don't know about best-practice - as long as it works...

But a note on naming: that rather looks like a "factory class", not like "converting to a subclass". If the class denominated by $self->{extension} has DUM::DUMMY in its @ISA, it is a subclass of DUM::DUMMY. Does the following (add sanity checks for @_ and such) fit into your design?

package DUM::DUMMY; use base 'DUM::Base'; sub new { my $class = shift; my %args = @_; my $ext; if ($ext = delete $args{extension} ) { my $backend = 'DUM::DUMMY::'.$self->{extension}; eval "require $backend"; if ($@) { # handle errors: die? return undef? set $@ ? } } my $self = $class->SUPER::new(%args); bless $self, 'DUM::DUMMY::'.$ext if $ext; $self; }

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Replies are listed 'Best First'.
Re^2: converting to a sub-class
by Cagao (Monk) on Oct 20, 2007 at 20:07 UTC
    Thanks, much appreciated, but I think that's adding more to the situation, i think a lot of comments have.

    I have My::Base.

    My::Waffle uses My::Base a base class to sort out new() methods, etc, also using Class::Data::Inheritable and Class::Accessor to sort things out for me (this My::Base class wasn't developed by me, but quite the "O'Reilly developer" who was recently working with us.

    I'm quite keen on just having My::Waffle::Whatever simply modify functionality from My::Waffle. The client will never know.

    Does that make any sense? Think about the Person 'class' idea mentioned before with a person class, the client creates a My::Waffle object, which then uses different versions of methods depending on different properties assigned by the client.

    Surely this can't be a new idea/feature wanted?
      mhm. Is that an issue of subclassing, of aggregation, or of mutiple inheritance? Difficult to tell without synopsis.

      See Anno's Alter package (RFC: Alter - Perl extension for Alter Ego Objects); may be that only adds to the confusion, but I have a gut feeling it addresses your problem. Maybe I'm wrong.

      If what you are doing is "method aggregation" (sorry for not using/knowing the canonical term for that), - if you want to call a method based on an object's attribute, you could just use that attribute to handle method dispatch via AUTOLOAD (which more aptly should be called AUTODISPATCH, since loading is only one use for it, as in AutoLoader). The loading of that attribute's package would have to be done in the object constructor.

      Example:

      sub AUTOLOAD { return if $AUTOLOAD eq __PACKAGE__.'::'.'DESTROY'; my $self = shift; (my $func = $AUTOLOAD) =~ s/.*:://; if ($self->{extension}) { my $method = join '::', __PACKAGE__, $self->{extension}, $func +; $method->($self,@_); } else { die "method $func not defined for $self\n"; }; }

      But that has the strong smell of reinventing a wheel. Method lookup based on object attribute? hmm...

      --shmem

      _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                                    /\_¯/(q    /
      ----------------------------  \__(m.====·.(_("always off the crowd"))."·
      ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
        Thanks Shmem, I think that might be what I'm looking for, and will look at that approach tomorrow, although it might not fit my needs.

        I'm also quite surprised that Class::Data::Inheritable and Class::Accessor seemed to break in the 2nd level of sub-classing, maybe i'm wrong, but without further digging that's what it seems. I don't believe it myself either. :-/

        Anyone out there with more experience of those modules and in this situation?