The four noisy horsemen of Perl hate

Re:The four noisy horsemen of Perl hate by forgotmypw17 on Wednesday July 21, 2021 @01:57AM (#27902799)

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;
    }

[ Parent | on HN ]

Re:The four noisy horsemen of Perl hate by motogpjimbo on Wednesday July 21, 2021 @03:38AM (#27903422)

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.

[ Parent | on HN ]

Re:The four noisy horsemen of Perl hate by arunix on Wednesday July 21, 2021 @05:20AM (#27904059)

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) = @_;
        ...

[ Parent | on HN ]

Re:The four noisy horsemen of Perl hate by motogpjimbo on Wednesday July 21, 2021 @10:10AM (#27906521)

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.

[ Parent | on HN ]

Re:The four noisy horsemen of Perl hate by BrandoElFollito on Friday July 23, 2021 @05:54PM (#27936054)

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

[ Parent | on HN ]

Re:The four noisy horsemen of Perl hate by forgotmypw17 on Thursday July 22, 2021 @12:04AM (#27915219)

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

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

[ Parent | on HN ]

Re:The four noisy horsemen of Perl hate by knightcrusader on Tuesday July 27, 2021 @01:31PM (#27975125)

Even easier than that:

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

[ Parent | on HN ]