in reply to Overloading inherited class methods

(You use _open_this_id in the top snippet, and open_id in the latter ones. I assume that's a typo.)

Instead of polluting the %ARGS hash (which can lead to threading problems should you ever go that way, and can royally confuse someone if they create a new instance of Foo::People without passing an _open_this_id pair, and then find that they've gotten an _open_this_id field with an id they didn't expect), why not do 

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

[download]
This nice thing about this approach is that it propogates up the chain of overriden methods nicely. That is, if Foo::People provides an %ARGS template, then it can both extend and selectively override an %ARGS template provided by Foo::PersistentObject. All without mucking up global state.

Replies are listed 'Best First'.
Re: Re: Overloading inherited class methods
by Ovid (Cardinal) on Dec 04, 2002 at 18:52 UTC

    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)

[reply]
[d/l]
      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