merlyn@xxxxxxxxxxxxxx (Randal L. Schwartz) writes:
>>>>>> "Junio" == Junio C Hamano <junkio@xxxxxxx> writes:
>
> Junio> Jakub Narebski <jnareb@xxxxxxxxx> writes:
>>> Make git_get_refs_list do also work of git_get_references, to avoid
>>> calling git-peek-remote twice. It now returns either list of refs as
>>> before in scalar context, or references hash and list of refs in list
>>> context.
>
> Junio> I do not think we want to have too many functions that return
> Junio> different things depending on contexts. Forcing callers to
> Junio> remember what the function does in which context is bad.
>
> That's even an inaccurate description, so an expert in Perl (I've
> known a few) would just scratch his head.
>
> You cannot ever ever return a list in a scalar context. Ever. Never ever.
That much I think I know.
The code I was complaining about tries to do something like
this:
sub that_sub {
...
return wantarray ? (\@bar, \%foo) : \@bar;
}
and it is not done for optimization purposes (i.e. "if the
caller only wants one and we are returning \@bar then we do not
have to compute \%foo which is a big win" is not why it does
this wantarray business).
So the callers when interested in the sequence of things in 'bar'
typically say:
my $the_list = that_sub(...);
for (@$the_list) {
...
}
while other callers say:
my ($the_hash, $the_list) = that_sub(...);
... use %$the_hash and @$the_list as see fit ...
And I was saying that getting rid of the "return wantwarray ? :"
business and write the first class of callers like this
my ($the_list) = that_sub(...);
for (@$the_list) {
...
}
would be much less confusing.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html