|
in reply to Re: How do I prototype a function with a varying number of arguments?
in thread How do I prototype a function with a varying number of arguments?
I myself am doing the same exact thing as you, basically making my subroutines "generic", (at least any subroutine I write that could ever be used again) more for my own code library and the benefit of the practice than a module or anything, but I haven't really taken the approach of using prototypes. At the mention of making my subroutines generic, my guru suggested using them, but upon my own research, I just didn't see the benefit, seems a bit redundant to me, perhaps I'm missing their functionality/purpose?
If there's any correlation between prototypes and genericness, it's a negative one. I'd say that prototypes make functions less generic.
In general, I don't use prototypes, unless they give me a benefit at compile time. Prototypes I may consider using:
- The empty prototype, for making constants.
- The single scalar prototype, ($), as it allows for making unary name functions, which are parsed differently: foo bar $baz, $quux; depending on the prototype of bar, $quux is a parameter for foo or bar. Note that I mean a prototype consisting of only a $, and nothing else.
- The give me $_ prototype, _. Have never used it so far.
- The coderef prototype, &, so I can pass in a coderef as a bareblock, instead of having to use the sub keyword. I don't think I've ever used & in a prototype other than (&@).
In all other cases, prototypes are much more of a hassle than they are worth it. And often, they are just plain annoying. |
Re^3: How do I prototype a function with a varying number of arguments?
by koolgirl (Hermit) on Jul 29, 2011 at 23:07 UTC
|
Your words are almost exactly what went through my head when I first began the research into prototypes, behind the suggestion I mentioned.
I'd say that prototypes make functions less generic.
I completely agree, I mean how is it, that putting a limitation on the number and type of arguments that can be passed to a function, make it generic and more suitable to use as a standby function?...That concept never made much sense to me. Glad someone else saw that. Now, as far as the reasons one might choose to use prototypes, I'm sure there are many great arguments, but for the point of creating generic functions, I agree that there doesn't seem to be a correlation.
| [reply] |
|
|
| [reply]
[d/l] |
|
|
How do you pass the elements of a two-item array to a function with the $$ prototype?
sub foo ($$) {...}
my @array = (1, 2);
&foo(@array);
;-) | [reply]
[d/l] |
|
|
|
|
oO
Instinctively, I think maybe this is a trick question, but, nonetheless....like this?
&sub ($@[0], $@[1])
I mean, technically a reference to a single array element is a scalar variable, so, that would work then....right?
| [reply]
[d/l] |
|
|
|
|
Hhmm, so, I'm sitting here looking at your question and my obvious answer, and I think maybe I'm seeing the point you maybe were trying to get me to see.....the $$ prototype isn't really a limitation, it's just a declaration of how many scalar arguments a function takes, like a <cmp> function, for example...or perhaps it's late and I'm thinking a bit too hard on this one.....
UPDATE:
OK, so I was thinking too hard...apparently it seems my original notions about prototypes making functions less generic is shared by quite a few of you out there. Well, this goes fantastic with one of my other recent posts, lol, especially related to planetscape's "brain fart" reply, which this last reply of mine most definitely seems to qualify as..*turns red* ;P
| [reply]
[d/l]
[select] |
|
|
|
|
