Re^2: How do I prototype a function with a varying number of arguments?

Replies are listed 'Best First'.
Re^3: How do I prototype a function with a varying number of arguments? by eyepopslikeamosquito (Archbishop) on Jul 30, 2011 at 13:45 UTC
In general, the consensus is that Perl 5's simple subroutine syntax is just a little too simple. Well, okay, it's a lot too simple. While it's extremely orthogonal to always pass all arguments as a single variadic array, that mechanism does not always map well onto the problem space. -- Larry Wall in Apocalypse 6 (2003) Yes, I see your point, so let me clarify. Minimizing variable scope is a sound general programming practice that I strive to employ in all languages I currently use (C++, Perl, Python, Ruby, Java). That is my strategic goal. This "unpack subroutine arguments at the top of the sub" business is just a pragmatic tactic used to work around Perl 5's primitive subroutine syntax. That is, in most languages, the scope of function arguments is the whole function and that is made plain by the language syntax. Explicitly unpacking Perl's appallingly non-descriptive `$_[0]`, `$_[1]`, ... subroutine argument names at the top of the subroutine to more meaningful lexically scoped names is usually the clearest way to express that these are indeed the function's arguments and that their scope is accordingly the whole function. In the common case of read-only subroutine arguments, it is also safer in that it avoids accidentally changing the passed arguments. The reasons behind this rule are described in detail in Perl Best Practices, along with exceptions to this rule (e.g. short and simple subs, when efficiency is critical, ...).	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: How do I prototype a function with a varying number of arguments?
by eyepopslikeamosquito (Archbishop) on Jul 30, 2011 at 13:45 UTC

In general, the consensus is that Perl 5's simple subroutine syntax is just a little too simple. Well, okay, it's a lot too simple. While it's extremely orthogonal to always pass all arguments as a single variadic array, that mechanism does not always map well onto the problem space.

-- Larry Wall in Apocalypse 6 (2003)

Yes, I see your point, so let me clarify. Minimizing variable scope is a sound general programming practice that I strive to employ in all languages I currently use (C++, Perl, Python, Ruby, Java). That is my strategic goal. This "unpack subroutine arguments at the top of the sub" business is just a pragmatic tactic used to work around Perl 5's primitive subroutine syntax. That is, in most languages, the scope of function arguments is the whole function and that is made plain by the language syntax. Explicitly unpacking Perl's appallingly non-descriptive $_[0], $_[1], ... subroutine argument names at the top of the subroutine to more meaningful lexically scoped names is usually the clearest way to express that these are indeed the function's arguments and that their scope is accordingly the whole function. In the common case of read-only subroutine arguments, it is also safer in that it avoids accidentally changing the passed arguments. The reasons behind this rule are described in detail in Perl Best Practices, along with exceptions to this rule (e.g. short and simple subs, when efficiency is critical, ...).

[reply]
[d/l]
[select]