"Charles K. Clarkson" wrote:
> Here begins my problems with prototypes. Let's try
> this sample script:
>
> sub generate_report_html([EMAIL PROTECTED]@);
which could also be written:
sub generate_report_html($$$);
with much greater clarity.
>
>
> my $title = 'foo';
> my @column_names = 1 .. 4;
> my @data = ( [1 .. 4], [5 .. 8] );
>
> generate_report_html $title, @column_names, @data;
would work well as:
generate_report_html $title, [EMAIL PROTECTED], [EMAIL PROTECTED];
>
>
> sub generate_report_html([EMAIL PROTECTED]@) {
> my ($title, $columns, $data) = @_;
> print "Report Done";
> }
>
> Everything is just fine until I decide to get my
> column names from a subroutine:
Perhaps because the sub neither does nor supervises the doing of any real work?
I don't think it would work if the sub tried to accomplish anything, given the
arguments offered.
>
>
> generate_report_html $title, column_names(), @data;
Do0n't use functions returning raw lists as function arguments. Function
arguments should be precise and predictable. If anything, the function called
by this should be prototyped:
sub generate_report_html ($$$$$@);
>
>
> sub column_names {
> return 1 .. 4;
> }
>
> Now I have to go into a library
Okay, Charles, now you are alluding to something we have no context to
understand. Are you saying that this would be the problem if the above function
were in a library, or ...
> and find out why
> things are failing and repair them. If I repair them,
> do I now have a problem with all the other programs
> written using that library of sub routines?
>
> I could massage the output of column_names() to
> work with generate_report_html(),
>
> generate_report_html $title, @{ [ column_names() ] }, @data;
>
> Or I could change the output of column_names(). But
> if column_names() is another library sub routine I'm back
> to square one.
>
> I like perl because I tend to not have to jump through
> hoops to program. Protoypes limit me too much. I'd rather
> not have to plan so far ahead when solving a problem.
>
> HTH,
>
> Charles K. Clarkson
HI Charles,
I agree strongly with your thesis, but in fairness, I would have to say that the
problems here arise more from type-confusion than from defects of prototypes
themselves. People seem to take that final @ in the prototype the wrong way.
My impression is that it essentially throws the prototype back open. All
arguments up to that bag sign @ are strictly prototyped. If the indicator is
\@, then the referennt of that scalar must be an array, likewise with \%. After
that point, if the list is terminated with a bag sign, then all further argument
become part of the bag, making the rest of the argument list equivalent to that
in an unprototyped function.
You could say that Perl subroutines, unless otherwise indicated have the
implicit prototype
sub_name(@);
indicating a single flat list, of indeterminate length, of scalars, some of
which may well be references to aggregates.
The bag indicator anywhere else in the prototype would create insoluble errors,
because the bag would take in all remaining arguments, leaving none to fulfill
any type specifications to follow.
Joseph
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
