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

[koolgirl]

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.

[chromatic]

... 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?

How do you pass the elements of a two-item array to a function with the $$ prototype?

[JavaFan]

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);

;-)

[ysth]

;) indeed.

[koolgirl]

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?

[chromatic]

I think maybe this is a trick question...

How do you pass the contents of a two-element array to an unprototyped function which takes two scalar arguments?

some_func( @two_elements );

How do you pass the contents of a two-element array to a $$ prototyped function?

some_func( $two_elements[0], $two_elements[1] );

That looks less generic to me, as it forces callee details to the caller side.

[koolgirl]

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

[eyepopslikeamosquito]

I think maybe I'm seeing the point you maybe were trying to get me to see.....the $$ prototype isn't really a limitation

Perhaps the point is that the $$ prototype can be a (confusing) limitation. For example:

use strict;
use warnings;

sub Fred($$)
{
   my $arg1 = shift;
   my $arg2 = shift;
   print "arg1='$arg1'\n";
   print "arg2='$arg2'\n";
}

my @two_elt_arr = ( 'abc', 'def' );
Fred(@two_elt_arr);                      # oops, compile error: "Not e
+nough arguments"
Fred($two_elt_arr[0], $two_elt_arr[1]);  # this works

See Modern Perl, "The Problem with Prototypes", page 242:

Prototype coercions work in subtle ways, such as enforcing scalar context on incoming arguments ... (examples elided) ... Those aren't even the subtler kinds of confusion you can get from prototypes.