lwall at scalpel
Sep 26, 1995, 10:47 AM
Post #3 of 4
(105 views)
Permalink
|
: > From: Paul Hudson <paulh [at] harlequin>
: >
: >
: > PM> 2. ($out_buffer, $status) = doit($in_buffer) ;
: >
: > I like ($status, $outbuffer) = ....
: >
: > It makes it clear the $outbuffer is a result, not an input, and makes
: > it slightly more difficult to ignore status than your original version
: > (since you have to put something to get the status value...)
:
: I've actually implemented my interface to be
:
: $out_buffer = doit($in_buffer)
:
: in a scalar context, and
:
: ($out_buffer, $status) = doit($in_buffer)
:
: in an array context.
Quibble: I'm calling it a list context nowadays.
: That is workable in my particular case because $out_buffer will only be
: undef/empty if the status is an error.
Yes, you get the most natural looking code if the data itself can carry
the success/failure signal. That's been a part of Perl's design from
the beginning. There are various ways to get the status information
on failure, but I don't believe in punishing the innocent with the guilty.
That being said, conformance to a published API is often the weightier
consideration, as Marc pointed out. But sometimes you can change things
a little, as long as you give a regular transformational rule, such as
"Always omit the buffer length." However, moving things to the other
side of the = is a bit of a stretch, unless the API is very regular
to begin with.
Larry
|
