in reply to Re: Overloading inherited class methods
in thread Overloading inherited class methods

Duh. That makes sense. Of course, if also pass %ARGS by reference, I don't have to worry about extra argments getting slurped up in the arg list. That's a nice benefit of pass by reference. That's a quick change that I think I'll go make.

Update: Ah, the beauty of test suites. Converting everything took me about two minutes and I can prove that is still works as well as it did :) Thanks for the help!

ok 1 - use Foo::People;
ok 2 - Foo::People->can('new')
ok 3 - The object isa Foo::People
ok 4 - Foo::People->can('open')
ok 5 - ... and opening with an existing id should succeed
ok 6 - Foo::People->can('get_company_id')
ok 7 - ... and it should return the correct company id
ok 8 - Calling a constructor with an ID should succeed
ok 9 - The object isa Foo::People
ok 10 - Foo::People->can('get_company_id')
ok 11 - ... and it should return the correct company id
ok 12 - Foo::People->can('get_list')
ok 13 - ... and it should return an arrayref of people
ok 14 - ... as objects:  isa Foo::People
ok 15 - Foo::People->can('get_company_id')

[download]

Cheers,
Ovid

New address of my CGI Course.
Silence is Evil (feel free to copy and distribute widely - note copyright text)

Replies are listed 'Best First'.
Re: Re: Re: Overloading inherited class methods
by dws (Chancellor) on Dec 04, 2002 at 18:59 UTC
    Of course, if also pass %ARGS by reference, I don't have to worry about extra argments getting slurped up in the arg list.

    But is that really a problem? The benefit of leaving the argument list flattened is that duplicates are taken care of automagically when you eventually do the   { @_ } in   bless { @_ }, $class; If instead you're dealing with a list of references to hashes, you have a lot more work to do in the constructor. Unless the hash arguments are going to get really big, I'd pass them flattened.

[reply]
[d/l]
[select]

      It was a problem here, but it may not have been completely obvious because I decided not to post the entire code of the superclass. However, the problem lies in issues like this:

        my ($class, %args) = @_;

      If that occurs, I might append extra data to %args that does not logically belong there in all cases. However, if I convert %args to a reference, I can keep my "extra" info seperate and I don't have to build as many special cases in my code to account for the extra hash keys:

        my ($class, $args, $id) = @_;

      (That's just an example, but you get the idea.) My problem lay in the fact that the subclassed constructor was expecting a single scalar id, which, if I passed the %args has from the get_list method, then the first element gets assigned to $id. Now, on second thought, I can see an error I made. I don't need to pass %args because the constructor already knows about it. Hmm... more work to do. Should take another two minutes :)

      Update: Took me less than two minutes, actually. Now my methods in the subclass look like this:

      sub new {
    my ($class,$id) = @_;
    $class->SUPER::new( %ARGS, open_id => $id );    
}

sub get_list {
    my $class = shift;
    $class->SUPER::get_list( %ARGS );
}

      [download]

      I am wondering now what would happen if I moved those into the superclass and exported them into subclasses (would that work? Then I wouldn't need to keep rewriting those methods for every class. I would just need to provide the %ARGS hash for configuration information and most objects would then simply use the superclass and have most of their methods just work. Interesting thought.

      Cheers,
      Ovid

      New address of my CGI Course.
      Silence is Evil (feel free to copy and distribute widely - note copyright text)

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom