develooper Front page | perl.perl5.porters | Postings from January 2022

Re: Things you can't do in a signatured sub

Thread Previous | Thread Next
From:
Ovid via perl5-porters
Date:
January 24, 2022 16:54
Subject:
Re: Things you can't do in a signatured sub
Message ID:
750973449.892738.1643043256917@mail.yahoo.com
On Monday, 24 January 2022, 15:59:55 CET, Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:


> Ovid via perl5-porters <perl5-porters@perl.org> wrote:
> > 
> > Imagine if we had a $^NUM_ARGS
> > variable (terrible name, though I think someone else suggested it):
> > 
> >     sub name ( $self, $name=undef ) {
> >         if ( $^NUM_ARGS == 2) {
> >             $self->{name} = $name; # even if undef
> >         }
> >         else {
> >             return $self->{name};
> >         }
> >     }
> 
> I've often suggested it as `argc` or variations thereon:
<snip>
>
> https://www.nntp.perl.org/group/perl.perl5.porters/2021/12/msg262142.html
>
> Dave M has rather strongly objected to it:

As an aside, but something we might want to keep in mind for future work, many languages simply don't have this issue because of method overloading:

    public void someMethod ( int number )  {
        // do something  
    }

    public void someMethod ( int number, String name ) {
        // do something else
    }

    public void someMethod ( int Number, SomeClass obj ) {
        // do something else
    }

It's clean, easy to read, and handles dispatching nicely. Of course, ambiguities can arise and in the Java examples above, dispatching is based on the number of arguments *and* the type of arguments. 

Allowing this in Perl would be a win because, IMHO, it's easier to read and matches existing, well-known conventions in other languages:

    method name () { return $name }
    # or method name :multi () { return $name }
    method name ( $new_name ) { $name = $new_name }
    # or method name :multi ( $new_name ) { $name = $new_name }

No, I'm not suggesting we do that, but this is (to me) much easier to follow. If types get incorporated at some point in the future, I have a ton of code that could be simplified by dispatching on type rather than if/else blocks. Overloading methods/subs allows us to have logically separated blocks of code for logically separate things.

Again, this is not a suggestion or a recommendation, but something to keep in mind. I'm happy to see signatures get out the door in their current state.

Best,
Ovid
-- 
IT consulting, training, specializing in Perl, databases, and agile development
http://www.allaroundtheworld.fr/. 

Buy my book! - http://bit.ly/beginning_perl

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About