On 2012-10-31 00:29:16, CJM wrote:
Show quoted text> The API would feel a lot more Perlish if it returned undef instead of
> the magic value $KEY_NOT_FOUND.
I agree that undef would certainly be more perl-ish than a magic
constant, and an early version (local only) of the code actually
returned undef from the "vb*" functions (which were the only ones
provided at the time). I chose to use the magic constant anyway for 2
reasons:
1) the underlying C code needs it anyways (return type is U32 ~ unsigned
32-bit integer), and returning it directly makes the XS code more
transparent (not a great reason, but file it under "maintainability").
2) the "vvb*" functions can't return undef in the result-vector, since
those are effectively just U32 values as well.
So basically, as it is now, I've ranked consistency and transparency
over perl-ishness: all functions return $KEY_NOT_FOUND for failed
searches, rather than undef for "vb*" and "vab*" functions and
$KEY_NOT_FOUND for "vvb*".
That said, I'm willing to move back to undef return values for "vb*" and
"vab*" if interest persists; but atm I'm tending to stick with the
current API.
Show quoted text> An alternative would be to change the module name along with the
> API, so existing users could migrate to the new API at their leisure.
Argh. I don't want to go there. I suppose I could offer a package-
global boolean configuration variable (e.g.
$Algorithm::BinarySearch::Vec::UNDEF_ON_FAIL) and (optionally) do the
mapping from $KEY_NOT_FOUND to undef on the perl side... opinions?
