Hash::Util's lock_keys

[Kent Fredric]

On 20 February 2014 01:16, Joel Bernstein <joel at fysh.org> wrote:

> Take a look at modules like Params::Validate, MooseX::Method::Signatures
> etc. In general, if you're passing complex data structures as method
> arguments, perhaps consider turning those structures into objects which can
> validate themselves, and passing those around instead.
>


And if you really wanted to, you could enable/disable strictly checking
passed parameters with an ENV value, which might give you some utility for
fault checking.

But some of your other arguments strike me as strange:

>> (1) it's additional code that has to be maintained and kept in sync with
POD, even if it's just one line;

Document it or not, if the code has an interface, whether or not you
document that interface is up to you.

>>(2) it can break legacy code  that passes attributes that are no longer
used

Well, so can simply acccepting parameters and ignoring their presence.
Though I'd have to see your code to know, it might vary between trivial and
unimportant, or it could be silently failing to do what was required.

I see "breaking legacy code" here as a kind of feature if legacy code is
attempting to use API that no longer exists.

Though my suggestion is primarily aimed at this problem, so you have a
control variable that toggles between "Fail during development so we can
detect problems" and "Silently try to keep going in production", if that is
how you prefer to work.

(4) most of CPAN isn't using this, notably Moo/Moose.

I'd say that depends on perspective, lots of cpan uses Parameter validation
and checking, which seems to be basically what you're using lock_hashes
for. While cpan may not be widespread in using that tool for that job,
there's plenty of tools that do similar things which are in use, and my
interpretation of what you wrote suggests you were not specifically asking
about Hash::Util, but the practice of hash  key validation in general.

( Though I've been known to grossly misinterpret things people have said
before, so my apologies if I'm way way off base )

-- 
Kent