Re^2: Pre/post subroutine assertions and documentation module?

I want something that verifies incoming parameters (usually a hash ref, so sub-keys) are correct, and also is designed in such a way that a short blurb can be added for viewing/extracting that describes the inputs.

It seems an obvious conjoining, if you are verifying inputs why not also document them, or vice versa. I may end up using something like Smart::Comments/Getopt::Euclid as a starting point for something of my own.

- Ant
- Some of my best work - (1 2 3)

Comment on Re^2: Pre/post subroutine assertions and documentation module?

Replies are listed 'Best First'.
Re^3: Pre/post subroutine assertions and documentation module? by tobyink (Canon) on Jan 12, 2012 at 19:59 UTC
These subs... are they intended to be called as functions, or as methods? If the latter, then something like Method::Signatures, or MooseX::Declare might be an idea.	[reply]
Re^4: Pre/post subroutine assertions and documentation module? by suaveant (Parson) on Jan 13, 2012 at 19:04 UTC
Methods AND subs, this is something I want to start applying to existing code, so switching to Moose is probably beyond scope. - Ant - Some of my best work - (1 2 3)	[reply]
Re^4: Pre/post subroutine assertions and documentation module? by educated_foo (Vicar) on Jan 12, 2012 at 20:29 UTC
something like Method::Signatures, or MooseX::Declare might be an idea. You mean "a terrible idea," right? Whether they're "functions" or "methods" (i.e. "functions where the type of the first argument determines the function to be called"), verifying input and output is the same.	[reply]
Re^5: Pre/post subroutine assertions and documentation module? by tobyink (Canon) on Jan 12, 2012 at 21:52 UTC
MooseX::Declare and its ilk allow the arguments to a method and (somewhat experimentally) the return value, to be declared in terms of Moose type constraints. A type constraint can use arbitrary code to verify that a value meets it. `subtype 'SmallInt' => as 'Int' => where { $_ < 10 };` [download] It allows the declaration of named parameters, and required and optional parameters. This seems to meet the "I want something that verifies incoming parameters" part of the quest. The reason I suggest that it's mostly useful for subs that are intended to be called as methods, rather than as functions, is that the declaration syntax offers certain shortcuts that make the assumption that the first parameter to will be a blessed object, and that the function body will want to refer to it as "`$self`". `class Person { # ... method thank (Person $person) { # ... } method accept_gift (Gift $gift) { $self->push_posession($gift); $self->thank($gift->giver); } } my $me = Person->new; my $bob = Person->new; my $dog = Gift->new(giver => $me, item => Puppy->new); $bob->accept_gift($dog); # ok Person::accept_gift($bob, $dog); # ok Person::accept_gift($dog); # dies` [download]	[reply] [d/l] [select]