in reply to Re^2: Question re SQL::Abstract (or something similar, whose existence I ignore!)
in thread Question re SQL::Abstract (or something similar, whose existence I ignore!)

You want to predefine a bunch of default values for various slots in @bind, but want to fill the rest in later, right? I.e. you want to curry the bind values, but not necessarily in order? And is your issue with substvars its opacity?

That general goal of defaults plus replacements tends to make me think "hash".

my %default_bind = ( age => 23, height => 75, birthday => undef ); my @key_order = qw( age height birthday ); sub { my $caller=shift; my @bind = @{ { %default_bind, @_ } }{ @key_order }; $rf->execute(@bind) or $caller->complain("Error executing this and that."); $rf->fetchall_arrayref; }

Or, assuming the order of arguments to the callback is well-defined, what about just doing the undef element replacement in-line? (Shown verbose for clarity):

sub { my $caller=shift; $rf->execute( map { defined $_ ? $_ : shift @_ } @bind ) or $caller->complain("Error executing this and that."); $rf->fetchall_arrayref; }

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Replies are listed 'Best First'.
Re^4: Question re SQL::Abstract (or something similar, whose existence I ignore!)
by blazar (Canon) on May 19, 2006 at 14:47 UTC

    This is certainly an interesting approach. "Philosophically" of the same breed as mine, IMHO, but somewhat cleaner.

    Of course I would rather prefer to be able to do something just as simple as

    $rf->execute(@_) or $caller->complain("Error executing this and that.");

    where obviously I may not really be using all of the (unprocessed) @_, but more realistically a list prepared from @_.

    my %default_bind = ( age => 23, height => 75, birthday => undef ); my @key_order = qw( age height birthday );

    Nice concept! Except that having to explicitly specify (some) keys in two places is again inelegant and error-prone. I would rather adopt some automatized mechanism along the same lines. Thanks for the input, anyway! It gave me an idea about the direction in which to proceed.