Re^5: When every microsecond counts: Parsing subroutine parameters

Yeah, there's a much better and cheaper way - don't name them, name the indices into @_ via constant subs, if you need names instead of numbers for sake of code clarity:

sub FOO () { 0 }
sub BAR () { 1 }

sub routine {
    my $bar = $_[BAR];
    $bar   += munge( $_[FOO] );
}
[download]

But it is crucial for that discussion to identify when it is beneficial to use named parameters, and why. I can think of:

frameworks - you write code that gets called, and there's a convention for what each call brings along. POE is a good example
looking up a subroutine or method - you want to make use of some subroutines you use seldom, and a quick glance should suffice to know what it needs
myriads of options - but mostly you need just a few of them. Tk is a good example for that

All other reasons seem to be based on gusto. But then, in early perl OO, objects were mostly blessed hashrefs (tutorials and perl pods are full of them), and much unreflected use of named parameters stems from there, I guess.

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Comment on Re^5: When every microsecond counts: Parsing subroutine parameters Download Code

Replies are listed 'Best First'.
Re^6: When every microsecond counts: Parsing subroutine parameters by BrowserUk (Patriarch) on May 18, 2008 at 07:18 UTC
Yeah, there's a much better and cheaper way - don't name them, name the indices into @_ via constant subs, Yeah! I demonstrated the potential for that back in Micro optimisations can pay off, and needn't be a maintenance problem & despite the jury's verdict, the performance gains attributable to minimising subroutine call overhead in that type of cpu intensive, heavily iterative (3d graphics with hidden line removal) are distinctly measurable. I'd only use this for subs that are unavoidably called at the centre of several levels of loop. The 2D & 3D Vector classes in the code in Re: Re^2: Micro optimisations can pay off, and needn't be a maintenance problem (I don't believe it) are a perfect example of the sort of code that can benefit from this technique. Any particular reason for using constant subs? It achieves the same thing, but to me use constant is just clearer of the intent and saves a little typing: `use constant { FOO => 0, BAR => 1 };` [download] What would be really cool is for an alternative sub declaration syntax that declared scoped constants for subs. Eg. `sub Point3D::new( CLASS, X, Y, Z ) { return bless [ @_[ X, Y, Z ] ], $_[ CLASS ]; }` [download] Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply] [d/l] [select]
Re^7: When every microsecond counts: Parsing subroutine parameters by shmem (Chancellor) on May 18, 2008 at 08:50 UTC
Any particular reason for using constant subs? Well, er... it's always the same reason for not using a module: I happily hack along, until... it gets boring. "Hey, that's boring!", I begin thinking, "isn't there a module?" ;-) --shmem _($_=" "x(1<<5)."?\n".q·/)Oo. G°\ / /\_¯/(q / ---------------------------- \__(m.====·.(_("always off the crowd"))."· ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}	[reply]