in reply to Re: OO Perl: calling a constructor within a class
in thread OO Perl: calling a constructor within a class

I'm not sure I like this polymorhic method-naming stuff that'll be happening in the background. Perl is weakly-typed, so why do a work-around that strongly-typed languages have to do? Instead, why not do the following? 
sub new {
    my ($class, $name, $rank, $c_num) = @_;
    $name ||= '';
    $rank ||= '';
    $c_num ||= '';

    bless { name => '',
            rank => '',
            cereal_number => '',
          }, $class;
}

[download]
That, to me, just feels cleaner and is more maintainable. If you make a change in new(), you only have to change it in one place. Especially if it's in a base class. If it's in a base class and you only change one, you suddenly have weird behavior in the grandchild classes and debugging it would take an age-and-a-half. *shudders*

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Replies are listed 'Best First'.
Re: Re: Re: OO Perl: calling a constructor within a class
by TheDamian (Vicar) on Sep 28, 2001 at 11:06 UTC
    Careful with that ||=, Eugene!
    Did you really want to prohibit a cereal number of zero?

    That's why I generally avoid using ||= to specify defaults.
    Unless I'm very sure my incoming data won't ever be 0, "0", or "".

    Besides, there are ways to tell if she is a witch: 

        $name  = '' unless defined $name;
    $rank  = '' unless defined $rank;
    $c_num = '' unless defined $c_num;

    [download]
    or: 
        foreach ($name, $rank, $c_num) { defined or $_ = '' }

    [download]
    or the strange-but-lovely: 
        $_ = '' for grep !defined => ($name, $rank, $c_num);

    [download]
    or the tried and true: 
        $name  = '' if weight($name)  == weight($duck);
    $rank  = '' if weight($rank)  == weight($duck);
    $c_num = '' if weight($c_num) == weight($duck);

    [download]

    Err...

    Oh, yes, I should also mention that next week, when Apocalypse III and Exegesis III appear, you'll find that Perl 6 is going to have a much nicer way to solve this problem.

    Damian

[reply]
[d/l]
[select]
      Perl 6 is going to have a much nicer way to solve this problem.

      I like the sound of that... last I heard there was some strong opposition to an ||= that tests for definedness rather than truthfulness. I've always been on the side of having such a construct, especially since ||= is so tempting for newbies to use, even *after* they've been told of the pitfalls.

      The only remaining question is what will the operator look like?

      -Blake

[reply]
[d/l]
[select]
        The only remaining question is what will the operator look like?

        if (tell $you) { require kill 9 => $you }

        ;-)

[reply]
        The only remaining question is what will the operator look like?

        I didn't tell you this, right, but you may find a clue here.

        --
        <http://www.dave.org.uk>

        "The first rule of Perl club is you don't talk about Perl club."

[reply]
Re: Re: Re: OO Perl: calling a constructor within a class
by runrig (Abbot) on Sep 28, 2001 at 01:02 UTC
    I agree that for this particular example a workaround is trivial and this module is probably not the best way to go, but I think the general idea of the module is great and can be used in non-trivial ways. And it might be one way to go for the original poster's problem, though (from my limited understanding of Class::Mulitmethods), he would have to do something more different than just passing in a simple scalar string with two different values, he would have to instead have different argument types or different numbers of arguments (Class::Multimethods doesn't seem to be able to dispatch based on the value of scalar args, just their type).
[reply]
      I would very much like to see a case in Perl where the exact same function name has to be used for two completely different functions within the same object. In fact, I put this up as a friendly challenge, runrig. Actually, it's open to anyone who cares to try. :-)

      ------
      We are the carpenters and bricklayers of the Information Age.

      Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

[reply]

In Section Seekers of Perl Wisdom