Last time we took a detailed look at MooseX-Types. In today’s article I want to show you the implications of coercions to global types, why you shouldn’t do it, and how to do it better.
Robert 'phaylon' Sedlacek: June 2009 Archives
While most people in Mooseland are using its core typesystem as if it’s been there all the time. The MooseX-Types extension on the other hand is a bit too much magic without obvious advantages to many people. To some it might seem a lot of work to create yet another module just to put some types in. Others might not see any value in using exports instead of strings. With this article I’ll try to show the why’s, the pro’s and the yay’s of designing type libraries with MooseX-Types.
Here are just some quick helping things that accumulated and I wanted to document:
From my .zshrc
These are some simple shortcuts for common perldoc functions:
alias perlsource='perldoc -m'
alias perlwhere='perldoc -l'
From my .gvimrc
For a long time I hated to have to type the package name after creating a new file
from hand. So I hacked up this little function to insert the part below the
lib directory as package name.
function! InsertPackageFromFile()
perl << EO_MAP
my ($row, $col) = $curwin->Cursor;
my $file = $curbuf->Name;
$file =~ s/\.pm$//;
use List::MoreUtils qw( after );
my $package = join '::',
after { $_ eq 'lib' }
split m{/},
$file;
my $line = join '',
substr($curbuf->Get($row), 0, $col),
$package,
substr($curbuf->Get($row), $col);
$curbuf->Set($row, $line);
EO_MAP
endfunction
map ,pp :call InsertPackageFromFile()<CR>
How about you?
Got any more Perl specific things to ease your daily routine?



