iblech writes:
And there's a Perl 6 way of doing it:
*Chuckle*
Actually, what I had the back of my mind was Perl 6's subtypes. In my original code, each CheckFactory corresponds to a named subtype, and each Checkee corresponds to an instance of the subtype.
Zaxo's Tie::Constrained module, to which another monk helpfully pointed me, works more like an anonymous subtype, in which you have to restate the constraint every time you want to constrain a new variable. That may mean Zaxo had a different application in mind (where each variable had different constraints, and the need to define a factory function would have just made the module harder to use); or it may mean he bumped up against the same problem I did, and couldn't find a way to write a good factory function to churn out identically-constrained variables.
Cheers,
Markus
| [reply] [d/l] [select] |
That may mean Zaxo had a different application in mind (where each variable had different constraints, and the need to define a factory function would have just made the module harder to use) . . .
You're exactly right about that. The original idea was just a bit of implementation to demonstrate validation for lvalue closures. My initial real application was to retrofit validation and detainting to cgi form processing scripts. No commonality was assumed for the variable types. It was later that I noticed more general applications for the module.
The idea of a factory-like method for constraining lists of variables is a good one. I'll add it to the TODO list. Here's an untested first cut at it:
use Tie::Constrained;
sub Tie::Constrained::tiethese {
my $self = shift;
map {tie $_, 'Tie::Constrained', $self} @_;
}
my $integer = Tie::Constrained->new(
sub { $_[0] =~ /^[+-]?\d+$/; }
);
my ($i,$j,$k,$l);
$integer->tiethese($i,$j,$k,$l);
As diotalevi said, functions return lists of values, not variables, so a method to tie a bunch of variables pretty much needs to be handed the variables and work with their aliases. You may not have noticed the constructor for unbound Tie::Constrained objects. I put that in to take the anonymity out of the subtypes and allow more readable ties with often-used constraints.
| [reply] [d/l] |
my subtype HasToBeDefined of Scalar where { defined $^a };
my HasToBeDefined $checked;
--Ingo | [reply] [d/l] |