4 ms·
that also highlights one of my perl peeves - having to scrape function args out of @_ rather than declaring them as part of the function definition.
by zem 14y ago
that also highlights one of my perl peeves - having to scrape function args out of @_ rather than declaring them as part of the function definition.
- jbert 14y agoYes, that sucks. It's not much extra typing: def function(x, y, z): versus sub function { my ($x, $y, $x) = @_; } The overhead is only really the 'my = @_;' chars, but it is annoying. On the other hand, it does allow you to do things like partially unpack args and pass the rest as a bundle to a super class.
- pyre 14y agoYou can partially unpack in Python too: def method(self, *args): a, b = args[:2] super(self).method(*args[:2]) Perl's lack of using the definition for the variables doesn't necessarily make it 'more powerful.'
- chromatic 14y agoPython's approach is very reasonable. Both Perl and Python are nicer than C varargs.
- berntb 14y agoMost of your life's problems can be solved at CPAN. :-) Just write: use Method::Signatures::Simple; http://search.cpan.org/~rhesa/Method-Signatures-Simple-1.02/lib/Method/Signatures/Simple.pm http://search.cpan.org/~rhesa/Method-Signatures-Simple-1.02/... But you might instead want to look at this (or similar with Moose support) to get simple type declarations: http://search.cpan.org/~barefoot/Method-Signatures-20120523/lib/Method/Signatures.pm http://search.cpan.org/~barefoot/Method-Signatures-20120523/...
- gamache 14y agoIt's really not that different; you just end up declaring your input arguments one line lower than in most other languages. Not a big deal in practice. And with @_, you're free to use positional arguments, named arguments, variable arity, etc. without penalty. Some languages only give you some of that.