Re: Hash::HasKeys
Ovid wrote: This is simple, but I'm tired of rewriting it. Params::Validate can handle it, but I don't want to fire up a diesel engine when this is all I need. Not sure if it's much lighter than Params::Validate, but a quick CPAN search points out Params::Check, which looks similar but with fewer bells and whistles. A quick look at the docs and code suggests you're not going to get much closer to your desired functionality and still be general enough for use by others. As with Params::Validate, you still have to write a specification indicating defaults and required arguments, but that's necessary even to do your own hand-rolled checks. It's almost embarrassing to upload a Hash::HasKeys module to the CPAN, but I rewrite this code *all* the time (and always forget about die if extra_keys()). Before I embarrass myself by writing and uploading something so simple and special-purpose, tell me there's something out there already ... Another option is to code a new subroutine macro into your editor that sticks it in for you from a template. (Quicker to delete if not needed than type it in.) I find that very useful in general as I stick in my Pod documentation template at the same time, too. Regards, David
Re: Hash::HasKeys
* David Golden [EMAIL PROTECTED] [2005-08-15 13:10]: Another option is to code a new subroutine macro into your editor that sticks it in for you from a template. (Quicker to delete if not needed than type it in. Do you debug the de Bruijn sequence…? :-) Regards, -- Aristotle “Like punning, programming is a play on words.” – Alan J. Perlis, “Epigrams in Programming”
Re: Hash::HasKeys
On Mon, 15 Aug 2005, David Golden wrote: Not sure if it's much lighter than Params::Validate, but a quick CPAN search points out Params::Check, which looks similar but with fewer bells and whistles. A quick look at the docs and code suggests you're not going to get much closer to your desired functionality and still be general enough for use by others. As with Params::Validate, you still have to write a specification indicating defaults and required arguments, but that's necessary even to do your own hand-rolled checks. Params::Check is in pure Perl, P::V is all in XS except for a few bits, so I'd guess P::V is going to be faster. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Hash::HasKeys
A. Pagaltzis wrote: * David Golden [EMAIL PROTECTED] [2005-08-15 13:10]: Another option is to code a new subroutine macro into your editor that sticks it in for you from a template. (Quicker to delete if not needed than type it in. Do you debug the de Bruijn sequence…? :-) Regards, Thank goodness for Google, as that went right over my head. For others who don't get the reference: http://perl.plover.com/yak/debruijn/ Let's just say I meant it in a narrower application. ;-) Regards, David
Re: Hash::HasKeys
A. Pagaltzis wrote:
* Dave Rolsky [EMAIL PROTECTED] [2005-08-15 14:55]:
Params::Check is in pure Perl, P::V is all in XS except for a
few bits, so I'd guess P::V is going to be faster.
But faster than merely locking a hash for a moment to keep
unwanted bits out of it too?
Regards,
It's not really clear what Ovid's objective function is and whether
execution speed is the issue. Points I heard include:
* Don't want to type this repetitively
* Don't want to forget to do something I should be doing regularly
* Large/confusing documentation is a turn-off to use
* Don't want a diesel engine
Does diesel engine mean slow? large? complex? The only question is
whether Params::Val9date
Personally, I like Params::Validate because the spec is very flexible and I
like something that I can use for simple things like required/optional
parameter checking or that I can scale up to more involved things like
argument validation or dependency checking. For Ovid's stated needs, this
approach using Param::Validate is sufficent:
use Params::Validate;
sub tweedledum {
my %args = validate( @_, {
foo = 1, # required
bar = 1, # required
bam = { default = 'default' },
wibble = { default = 0 },
wobble = { default = 0 },
});
# process
}
It's hard to imagine something more spare than that that is still
intelligible and maintainable. It even generates the error messages, which,
aside from the spec, is the lengthier thing to hand-roll. (The check for
extra/missing keys bit is actually really simple.) Even Params::Check is
not much different in terms of API.
And I'm not sure if argument processing is really the best point of
optimization. If argument checking time is equal or greater than subsequent
processing, and that subroutine really is the bottleneck, then it should
probably just be inlined anyway.
Regards,
David
Re: Hash::HasKeys
Le lundi 15 août 2005 à 11:01, David Golden écrivait:
use Params::Validate;
sub tweedledum {
my %args = validate( @_, {
foo = 1, # required
bar = 1, # required
bam = { default = 'default' },
wibble = { default = 0 },
wobble = { default = 0 },
});
# process
}
plug type=shameless
For all you metasyntactic needs, don't to use forget Acme::MetaSyntactic!
/plug
Exemple:
$ meta donmartin 6
chook
plablablablab
ga_shklurtz
spritz
fladip
swap
--
Philippe BooK Bruhat
To flaunt your strength is to make it your weakness.
(Moral from Groo The Wanderer #25 (Epic))
Re: Hash::HasKeys
On Aug 13, 2005, at 12:25 PM, Ovid wrote: --- Mark Stosberg [EMAIL PROTECTED] wrote: On Sat, Aug 13, 2005 at 07:27:56AM -0500, Ken Williams wrote: Before discounting it, have you measured the actual resource impact? I would hope it would be fairly minimal, in it's mode of disabling validation: http://search.cpan.org/~drolsky/Params-Validate-0.78/lib/Params/ Validate.pm#DISABLING_VALIDATION Looking at the first sentence of that section: If the environment variable PERL_NO_VALIDATION is set to something true, then validation is turned off. This may be useful if you only want to use this module during development but don't want the speed hit during production. So if I want to avoid the performance impact of Params::Validate, I have to not do what I want to do. I wasn't asking about P::V's disabled mode (I never use that either), I was asking if you actually know its performance hit is too much in its enabled mode. Have you benchmarked? -Ken
Re: Hash::HasKeys
--- A. Pagaltzis [EMAIL PROTECTED] wrote: Even if Iâve not convinced you, I know this will be what Iâll be doing henceforth. :-) OK, I'm convinced. I played around with it for a bit it's close to what I want. The reason it didn't seem like an option at first is the documentation does not make it clear I can lock a non-existing key and later assign a value. I suppose the docs *could* be read that way, but if the docs explicitly said that the restricted keys may contain keys not already present in the hash, I'd have understood. Thanks! Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Hash::HasKeys
--- Ken Williams [EMAIL PROTECTED] wrote: I wasn't asking about P::V's disabled mode (I never use that either), I was asking if you actually know its performance hit is too much in its enabled mode. Have you benchmarked? No. I was trusting my boss's reasoning for not wanting to use P::V and when I saw all of that documentation when I just wanted to check the darned keys, I thought I don't need all of that. Of course, I also whine quite a bit about Perl's awful argument handling, so I suppose I should buck up and take a look at the module. I'm just being silly not doing so. Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Hash::HasKeys
On Sun, 14 Aug 2005, Ovid wrote: No. I was trusting my boss's reasoning for not wanting to use P::V and when I saw all of that documentation when I just wanted to check the darned keys, I thought I don't need all of that. Well, it's definitely overhead. The question is if it's much more overhead than some other function you write to handle checking for key existence and assigning defaults. Of course, I also whine quite a bit about Perl's awful argument handling, so I suppose I should buck up and take a look at the module. I'm just being silly not doing so. I'd say so, but I'm biased ;) I'm very much wishing that P::V can disappear entirely in Perl6, and I'm probably going to confirm that on the p6l list, because in the end it's just a nasty hack. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Hash::HasKeys
On Sun, Aug 14, 2005 at 06:18:38PM -0500, Dave Rolsky wrote: I'm very much wishing that P::V can disappear entirely in Perl6, and I'm probably going to confirm that on the p6l list, because in the end it's just a nasty hack. I find P::V quite useful, and more elegant that the longer-winder parameter processing I've done as an alternative. I, too, I am looking forward to enhancements in this area in Perl 6. Mark -- http://mark.stosberg.com/
Re: Hash::HasKeys
Ovid wrote: I rewrite this code *all* the time (and always forget about die if extra_keys()). Repeated code is a mistake: I learned that lesson (from mjd, natch) very well. And as a result, got over any shame about putting simple code into subroutines; then into modules, when I used it in more than one program; then up on CPAN if I couldn't find anything lazier. Before I embarrass myself by writing and uploading something so simple and special-purpose, tell me there's something out there already ... That, IMHO, would be the only reason *not* to upload something to CPAN. Perhaps you could flesh your example out a bit more; I wasn't entirely clear on your objective. jimk
Re: Hash::HasKeys
* Ovid [EMAIL PROTECTED] [2005-08-12 23:40]: Just another example of why I shouldn't be retyping this :) Well, the one point you haven’t replied to, which I’m still wondering about: is there a reason to avoid Hash::Util::lock_keys for your task? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Hash::HasKeys
--- Terrence Brannon [EMAIL PROTECTED] wrote: I may be off-base because you are calling extra_keys() and I don't see it defined, I didn't define it because that was just an example to show what I want. but in principle, whatever you upload should have the exception-like action abstracted so people can take whatever action they want? And list the offending data? Yes, that thought had occurred to me, too, but only so long as it's simple. I just want something that does this one thing well. Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Hash::HasKeys
Hi all,
Sometimes the CPAN doesn't provide the trivial things I need. For
example, I am often doing something conceptually similar to this:
sub foo {
my $args = shift;
croak $message unless is_deeply [sort keys %$args], [EMAIL PROTECTED];
foreach (@default) {
$args-{$_} = $some_default unless exists $args-{$_};
}
croak if extra_keys($args);
# do stuff
}
This is simple, but I'm tired of rewriting it. Params::Validate can
handle it, but I don't want to fire up a diesel engine when this is all
I need.
It's almost embarrassing to upload a Hash::HasKeys module to the CPAN,
but I rewrite this code *all* the time (and always forget about die if
extra_keys()). Before I embarrass myself by writing and uploading
something so simple and special-purpose, tell me there's something out
there already ...
Cheers,
Ovid
--
If this message is a response to a question on a mailing list, please send
follow up questions to the list.
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Hash::HasKeys
* Ovid [EMAIL PROTECTED] [2005-08-12 22:15]:
sub foo {
my $args = shift;
croak $message unless is_deeply [sort keys %$args], [EMAIL PROTECTED];
foreach (@default) {
$args-{$_} = $some_default unless exists $args-{$_};
}
croak if extra_keys($args);
# do stuff
}
I don’t know if this is just a silly example, but I’m not sure it
makes sense… why `die if extra_keys` when you’ve already made
sure that the set of keys can only be exactly @some_keys? Why set
a for all keys *unless* they exist, when you’ve already required
exactly the set of @some_keys to exist? And why use the same
default for all of these?
The code I use for such occasions is
sub foo {
my ( $args ) = @_;
my %default = ( foo = 1, bar = 1, baz = 'quux' );
my @optional_keys = qw( wibble wobble );
my %args = ( %default, map {
exists $args-{ $_ } ? ( $_ = delete $args-{ $_ } ) : ()
} keys %default, @optional_keys;
croak I have no idea what you mean by @{[ keys %$args ]} if %$args;
# ...
}
And I guess that could stand to be encapsulated for
sub foo {
my ( $args ) = @_;
my %args = defaultify_hash(
$args,
{ foo = 1, bar = 1, baz = 'quux' },
[ qw( wibble wobble ) ],
sub { croak I have no idea what you mean by @_ },
);
# ...
}
But I’d be unlikely to ever depend on a module that provides
nothing but `defaultify_hash` unless it’s in core. Otherwise I’d
just copypaste the function…
But then, the likely candidate is Hash::Util, and if you’re going
to require that, you can already rewrite the code as
sub foo {
my ( $args ) = @_;
my %args = ( foo = 1, bar = 1, baz = 'quux' );
Hash::Util::lock_keys( %args, keys %args, qw( wibble wobble ) );
eval { %args = ( %args, $%args ) };
croak $@ if $@;
# ...
}
at which point trying to reuse this little code gets kind of
silly. Thinking about it, this may be how I’ll implement this
henceforth… I don’t like 5.8.1 anyway because Unicode is too
important to me…
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Re: Hash::HasKeys
--- A. Pagaltzis [EMAIL PROTECTED] wrote:
I donât know if this is just a silly example, but Iâm not sure it
makes sense⦠why `die if extra_keys` when youâve already made
sure that the set of keys can only be exactly @some_keys?
Oops. That was silly of me. Just another example of why I shouldn't
be retyping this :)
My first line should have been something like:
croak $error
unless @required == grep {exists $args-{$_}} @required;
The code I use for such occasions is
sub foo {
my ( $args ) = @_;
my %default = ( foo = 1, bar = 1, baz = 'quux' );
my @optional_keys = qw( wibble wobble );
my %args = ( %default, map {
exists $args-{ $_ } ? ( $_ = delete $args-{ $_ } ) :
()
} keys %default, @optional_keys;
croak I have no idea what you mean by @{[ keys %$args ]} if
%$args;
# ...
}
Yes, but you're altering the hash passed in by reference.
Cheers,
Ovid
--
If this message is a response to a question on a mailing list, please send
follow up questions to the list.
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Hash::HasKeys
* Ovid [EMAIL PROTECTED] [2005-08-12 23:40]:
Yes, but you're altering the hash passed in by reference.
Fair point, and trying to avoid that does get ugly. I don’t run
into it much because I usually take named params directly in @_
instead of via a hashref.
sub foo {
my ( $args ) = @_;
my %default = ( foo = 1, bar = 1, baz = 'quux' );
my @optional_keys = qw( wibble wobble );
my %have_keys = map { $_ = undef } keys %$args;
delete @have_keys{ keys %default, @optional_keys };
croak I have no idea what you mean by @{[ keys %have_keys ]} if
%have_keys;
my %args = (
%default,
%$args,
map { exists $args-{ $_ } ? ( $_ = $args{ $_ } ) : () }
@optional_keys,
};
# ...
}
But the point still stands that I’d be likelier to keep a copy of
a function for this purpose in my snippets file than to depend on
a module that doesn’t provide anything but it.
Also the point about lock_keys, which makes all of this a
non-issue.
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
