Hacker News Reader

Comment by forgotmypw17 | Hacker News Reader

What you're describing is called subroutine signatures in Perl, an "experimental" feature I remember using on production in 2004.

At the time, I thought it made a lot of sense, after using other languages where this feature was standard and required.

However, I've since abandoned its use in Perl, because the traditional Perl way is much more flexible.

I do try to keep my `shift` statements towards the top of a sub, however.

    sub PaintHouse {
        my $house = shift;
        my $color = shift;

        if (!$house || !$color) {
            WriteLog('PaintHouse: warning: sanity check failed');
            return '';
        }

        print "painting $house with $color paint";

        return 1;
    }

View on HN

I've never written Perl code, but I'm going to make a wild stab in the dark here and guess that the "flexibility" you're talking about involves putting the `shift` keyword half way down the function body, putting it inside `if` statements, putting it inside loops etc?

If so, that's not the kind of flexibility I ever want to see in a programming language.

No, the flexibility on offer is that you get regular arguments, optional arguments, variable numbers of arguments and keyword/named arguments all as a result of this mechanism.

I hardly ever use shift like this, preferring instead the more readable argument copying:

    sub PaintHouse {
        my ($house, $color) = @_;
        ...

I work in a legacy codebase (in PHP, not Perl) where the previous developer often wrote functions to be excessively flexible with regards to their parameters - many of the parameters are optional, some of them behave differently depending on whether they're passed as strings, integers or booleans, arrays can be passed as either flat or associative arrays, etc.

I'm sure he thought he was making his functions easier to reuse in different contexts but in practice the actual result is that it's impossible to modify any of those functions without considering _every possible_ combination of parameters that could be passed in. Often what should be a simple fix becomes something much more time consuming.

There is a place for flexibility in software design, but the parameter list of a function is not one of those places in my opinion.

I was inclined to do so on python and was reluctant to use a typed language.

I tried Go and Typescript and realized that the extra code is really, really worth the security, refactorability and safety.

I now frown on my beloved Python for being so permissive

    my $house = shift;
    my $color = shift;

    if (!$color) {
        $color = GetDefaultHouseColor();
    }

Even easier than that:

  my $house = shift;
  my $color = shift // GetDefaultHouseColor();

Reply on news.ycombinator.com