[Mpls-pm] Closure Code Samples

[Robert Fischer]

Joshua --

Wow.  That's way more into the code than I intended for anyone to look.  :D

> In the following snippet, you either didn't have enough parentheses or
> should have used || which has a higher precedence than or.
> $prevShift = $prevShift or sub ($) { return shift }
>
Yeah, that's my bad.  Thanks for the catch.  I didn't test or even compile
that code -- I just wrote it off the cuff -- so take it with a grain of
salt.

> In your code, you use the magic numbers 215 and 221as parameters to
> substr when date "parsing". What's that about?
>
They're just magic values that come from the business rules being applied
at that particular point: feel free to ignore them.  :D

> You used prototypes on functions. This is nearly always a bug. I'd
> just reference Tom Christiansen's "FMTEYEWTK about Prototypes in Perl"
> which google just located at
> http://library.n0i.net/programming/perl/articles/fm_prototypes/. The
> set of problems that it introduces is well known. If you're not aware
> of them you should give that document a gander.
>
I've read that article, and I'm unconvinced.  Yes, prototypes often do
things you might not intend them to do (e.g.: length(@arr)) -- on the
other hand, what would be the alternative?  Assuming length is designed to
work on just the first element (and doesn't check for having too many
elements passed), you're going to get the length of the first element of
@arr in the previous example.  Furthermore, there's the whole slew of
+1/-1/etc./etc. issues that resulted in the creation of prototypes in the
first place, and I'm willing to consider those more significant, although
Tom dismisses them.

The major issue is that people don't understand what prototypes are, and
they are expecting them to do things they don't do, or to not do things
they do (like force context).  Like so many things in Perl, you should
only use them once you understand them, and you can really hurt yourself
if you happen to be using them wrong.  I don't tend to use those patterns
that Tom laments (e.g.: passing a two-element array to denote the two
arguments of a subroutine), so I find prototypes to be a good way to tip
the compiler off and check my own mess.

Of course, my personal opinion is that the correct solution is implicit
static types, like OCaml has:
http://caml.inria.fr/pub/docs/manual-ocaml/manual003.html

But, then again, I'm particularly biased.

> I tried swapping all of your parameter validation for Params::Validate
> while this is just my opinion, it turned out to be oodles easier to
> read.
>
I never looked into Params::Validate before.  Thanks for the tip.

~~ Robert Fischer.
rfischer at corradiation.net
651-398-8010