in reply to Re: Re5: Calling SUPER in MethodMaker-generated methods
in thread Calling SUPER in MethodMaker-generated methods

Would you accept a small tip via PayPal

Nah, don't sweat it. I enjoyed helping. :) I appreciate the offer, tho.

Update: Re: your code; I just wanted to point out that you should probably either put the assignment to @parent_slots inside the eval, since it's conceivable that the super-method could correctly return an empty list which would cause your code to die, or make the test for dying an explicit check on $@ (in which case the 1; at the end of the eval is superfluous). IOW, it's best to do this:

@parent_slots = eval "package $class; \$self->SUPER::$method_name()"; die $@ if $@;

Also, if you're going to pass @_ in to the super-method, you need to shift $self off first, instead of setting it via list-context assignment. (Otherwise, the super-method gets two copies of $self.)

bbfu
Black flowers blossom
Fearless on my breath

Replies are listed 'Best First'.
Re: Re7: Calling SUPER in MethodMaker-generated methods
by danb (Friar) on Jul 09, 2003 at 17:42 UTC
    Thanks. I rewrote it slightly:
    ##################################################################### ## CustomMethodMaker ## (must be in it's own file, due to the fact that it has to be 'used +'. ##################################################################### package Business::Shipping::CustomMethodMaker; use base ( 'Class::MethodMaker' ); =head2 grouped_fields_inherit Works like grouped_fields, except that it also calls the parent class. =cut sub grouped_fields_inherit { my ($class, %args) = @_; my %methods; foreach (keys %args) { my @slots = @{$args{$_}}; $class->get_set(@slots); my $method_name = $_; my $caller = $class->find_target_class(); $methods{$_} = sub { my $self = shift; # #print "installing $method_name() in $caller...\n"; # # Without $caller and eval, the following line causes this err +or: # # Can't locate auto/CustomMethodMaker/SUPER/[METHOD].al in @IN +C # my @parent_slots = eval " package $caller; if ( \$self->can( SUPER::$method_name ) ) { return \$self->SUPER::$method_name( \@_ ); } else { return ( ); } 1; "; die $@ if $@; return ( @parent_slots, @slots ); }; } $class->install_methods(%methods); } 1;
    -Dan

      I was thinking about this a little over the weekend, and I realized why SUPER needs to check the current package's @ISA, instead of the package into which the object is blessed. It's to handle the case where the super-method also uses SUPER. If it just used the @ISA of the package the object was blessed into, SUPER in a super-method would start over at the bottom (top?) of the inheritance tree. So it has to use the current package, which is also the current position in the inheritance tree, except for the one case that you happened to run into. Anyway, that's the "why" of it.

      I also realised that it's probably a bit more efficient to do the eval once, when creating the anonymous sub, instead of every time it's called (although it may be a case of premature optimization... I'm not entirely certain). Like so:

      $methods{$_} = eval qq( package $caller; sub { my \$self = shift; # #print "installing $method_name() in $caller...\n"; # # Without \$caller and eval, the following line causes this error: # # Can't locate auto/CustomMethodMaker/SUPER/[METHOD].al in \@INC # my \@parent_slots; if ( \$self->can( SUPER::$method_name ) ) { \@parent_slots = \$self->SUPER::$method_name( \@_ ); } return ( \@parent_slots, \@slots ); } ); die $@ if $@;

      Just thought I'd share those, for completeness.

      bbfu
      Black flowers blossom
      Fearless on my breath