A perl of your own
Want per project perl defaults that save boilerplate? You want your perl - you want myperl.
Matt S Trout (mst)
A blog about the Perl programming language
mst
Free blog hosting for users of the Perl Programming Language
Syntax::Collector is similar.
swuecho, Syntax::Collector is in the same class as ingy's perl5 or SineSwiper's sanity (and somewhat related to my Import::Into). All of them involve your adding a 'use' line to your code; the point of myperl is to be able to have whatever boilerplate you want without having to add even a single line to your code.
So, similar goal, but a very different (and I hope for some purposes better) way of doing it.
Matt,
1. Do you plan to add support for boilerplate besides "use"? E.g. the "1" at the end of all pm files and "__PACKAGE__->meta->make_immutable;" as often the sane default in Moose?
2. I understand and applaud your effort to sidestep the discussion while concentrating on the "Pumpkin Perl" discussion. But while I agree that deciding on defaults is more difficult than herding cats, I can't help feeling that what this module really does is just making the boilerplate higher-level, not getting rid of it. At the end, it will be there in the released code
Java "fixed" the problem by creating good IDE's to make it easy to autogenerate repetitive and verbose code constructions (==boilerplate). Reading "Map map = new HashMap" still hurts my eyes.
Anyway, thanks for actively thinking about Perl's future.
Claudio
Funny on how the comment system ate my java generic example :) Imagine a "String, String" with less and more than on both sides of the statement :)
Hmm. I'll have to look to see if I can use that to improve my 'everywhere' module. It is a pretty similar concept, except that 'everywhere' is designed to be used in your top-level wrapper script on a per-application basis.
nxadm, 'use true;' gets rid of the 1; and MooseX::AutoImmute demonstrates a solution for ->meta->make_immutable (in Moo, immutability happens automatically on first ->new).
What I'm looking at here is a way to evolve a set of defaults without needing to understand any of the cleverer approaches - in my case, I think I'd rather have it imply 'use MyApp::Defaults;' or similar and centralize everything there with Syntaxt::Collector or sanity.pm or whatever - but I figured first I'd do the simplest thing that could possibly work and experiment.
I've got a pull request outstanding already that handles ~/.myperl and provides an environment variable; if you want to play around with changing the rewriter to generating a Syntax::Collector/sanity module and prepending a single line to invoke that to the .pm and script files, I'd be interested.
-- mst
Never heard of "use true". Thx. The idea looks interesting.
To nitpick: there are a lot of (potentially well written) admin/devops-code there that does not have a proper cpan project structure. It may be bad, but it's certainly a real world scenario, even for people writing modern Perl. I think specifically of longer nagios plugins, and the like. I guess it's impossible to make everyone happy, but it good to know what the limitations are.
C.
nxadm, I think those people are as served as they're going to get by the capacity to have single-line feature bundles.
Getting from 'one line' to 'no lines' requires a trade-off - in this case 'run this using the myperl script, or apply myperl-rewrite to it'. Doc patches making this clearer would be welcome, but you can't have 'no lines' and 'your old code still works', and I somehow doubt nagios would be amazingly impressed if we broke half the existing plugins to make it easier to write new ones :)