mccs
But no directory listing (at this time)]]>
Plack::App::Directory
behaviour better than my own suggestion because it shows the access logs. It has been suggested twice on Twitter, so it seems to be fairly known. Too bad it's not part of core Perl or default Perl modules installed by the OS distros.http://search.cpan.org/dist/Catalyst-Plugin-XSendFile/lib/Catalyst/Plugin/XSendFile.pm
http://www.perlmonks.org/?node_id=1000255
Basically you add a response header then Apache or lighty serves the file for you. That is much more efficient than serving it from Perl.
Cheers -- Rick
There are several reasons I did not use looks_like_number()
:
Inf
and NaN
;'2'
and '3'
in the string '2+3'
, but looks_like_number()
will not do this.That said, I would agree that qa[] is the most natural way of using qa().
]]>If you think qk() should return a hash ref instead, that's a different discussion, but I think consistency with the baked-in feature qw() outweighs consistency with the proposed feature qa[]. Also, I typically store membership hashes in plain hashes because
drive($car) if $is_working{$car};
is a bit cleaner than
drive($car) if $is_working->{$car};
so given my druthers, qk() would return a plain hash.
qa()
, because of how little they offer, and how easily they are replicated by just chucking a few functions into List::Util:
our $cars_ref = array qw(sedan hatchback coupe);
our %is_color = members qw(red blue green);
… and though array
may not seem worth it, it does have the advantage over []
that you can often leave off the parentheses in the function call, in which case it offers prefix notation rather than the built-in circumfix.
Then old perls can easily run this code by just upgrading their List::Util.
A thought I’ve had a number of times, though, is that I’d like for simple slices to be allowed within declarations, so you could say things like this:
our @is_color{qw(red blue green)} = (1) x 3
… and this would declare %is_color
while assigning to it. And same thing for array slices.
This feature generalises to many more situations than qa()
and qk
, e.g.
sub new {
my ( $class, @self{qw( id name label )} ) = @_;
bless \%self, $class;
}
The problem is that we don’t have someone like Larry any more who a) tries to keep the design of the language as a whole in their head and b) has the legitimacy to say “no” to nice-looking but ultimately ill-fitting proposals for consistency reasons. (And I’m not saying it’s my proposal that Larry would keep; maybe mine is the crazy one, and he would go with something completely different.) This was of course precisely the problem with the RFC process that factored into why Perl 6 became such a huge undertaking – namely, almost every proposal was one-off solution focused on one corner of the language, and however reasonable they were individually, putting all of them together would have made a huge mess of the language.
]]>
my $aref = qa( a b c );
## vs
my $aref = [qw( a b c)];
my %h = qk( a b c )
my $h = { qk(a b c ) };
]]>
In my opinion, qk() offers clearer code, and that's not a little thing. I will not comment further on qa() since it isn't my idea, although I personally like it.
they are replicated by just chucking a few functions into List::Util
While qa() and qk() could indeed be provided as a function in List::Util (or List::MoreUtils), Perl has plenty of core features that could have (should have?) been implemented as modules. For example, say. Perl also has lots of core features that offer relatively minimal benefit given a scope of "all Perl programs" (e.g. getprotoent).
Based on my CPAN search, I think qk() would get pretty heavy use.
I'd like for simple slices to be allowed within declarations, so you could say things like
our @is_color{qw(red blue green)} = (1) x 3;
I agree that being able to declare-and-initialize a hash using the slice syntax would be helpful. However, in this case I'd still use
our %is_color = map { $_ => 1 } qw(red blue green);
(or qk(), of course) instead of
our @is_color{qw(red blue green)} = (1) x 3;
because with the latter, you have to change two things every time you add or remove something from list: the actual list, and the literal 3;
I read Mark-Jason Dominus's post you linked to, and I will admit I am not a "Perl internals" guy. And maybe, per that same post, this is tunnel vision on my part since I would use this feature a lot. But I hope not, based on my CPAN search.
]]>In this case thanks should go to the folks from the Debian Perl Team, Gregor Herrmann and Dominique Dumont.
They kept reminding us to do this change ;-)
Forgot to mention them in the post, as it was late yesterday
]]>But for YAML that's not unusual, and people don't expect it to do potentially dangerous things by default.
]]>