bye

Warnings are good, damnit!

Warnings highlight possible bugs. The presence of a warning does not necessarily indicate a bug.

Only valid constructs will generate warnings! If a construct were invalid, then the system would have issued an error.

Warnings are not only for new learners. Warnings are also useful to experts, especially in the context of an evolving system. Delegating vigilance to the environment alleviates the burden of maintenance.

Changing code to cease its issuance of warnings usually requires disambiguation. This disambiguation is beneficial, because unambiguous code is clearer than ambiguous code. Encode your intent so that current collaborators and future maintainers will not have to guess at it.

If you truly require your code to run without warnings, then disable warnings entirely. The creation of warnings for potentially misleading or unexpected behavior should never require a battle. Existing code will not become incorrect, because warnings are not errors. However, you should still strive to correct the problems that issue warnings in new and maintained code.

edit: Some have missed the point of this post. I am not saying that having your code spew warnings is good in itself. I'm saying that having some warnings to alert you to suspicious code and to guide your fixes is what is good.

MooseX::Role::Parameterized

Moose supports this feature too, through the MooseX-Role-Parameterized extension I wrote a little over a month ago. It has proved to be a very useful pattern. I'm pleased that Perl 6 has it built in.

Out of curiosity, I ported the examples Jonathon provided to MXRP. I'll have to work more with rafl to make MooseX-Declare support something resembling Perl 6's much nicer syntax. We do plan on having syntax for positional parameters in much the same way Perl 6's parametric roles do.

I'll skip the second example because it's contained by the third example.

Moose doesn't give you multiple dispatch. sigh! Instead we model the problem with a default value for the transform, which is a code reference. In this way we meet the original requirement of EnglishMan and Lolcat not needing to provide a nominative->accusative transform.

Devel::REPL: now with multiline support

I've been using Devel::REPL for a while now. Like all good modules
(Perl::Critic, POE, Plagger, etc), it's very extensible. Devel::REPL's design is worth
studying: keep a simple core and ship all the fancy behavior as plugins.
Moose amplifies the power and convenience of this design with roles,
method modifiers, and general awesomeness.

There are plugins to dump output with Data::Dump::Streamer, enable tab
completion of the current lexical environment and loaded modules, save
input history across sessions, and more. However, if you dabble in other P-languages such as Python and Ruby (know thy enemy.. honest!) you'll find
yourself wanting more out of Devel::REPL. Let's take the example of writing
a factorial function in python:

Well, that works in this case, but one big line of code quickly becomes
unmanageable.

Recently I had the idea to use PPI to figure out if the current line of
code is complete. PPI::Dumper quickly confirmed that I can detect the most
important case: a PPI::Structure that doesn't have both a ->start and ->finish.
Structures encompass { {nested { blocks } } }, (parentheses), [array indexing], {hash
indexing}, and so on. Hopefully future versions of PPI will be able to
figure out that, say, an s/// or quoted string is incomplete.

Here's what the factorial example looks like with the MultiLine::PPI
plugin.

I believe Devel::REPL is the only Perl REPL that can do this. Hooray!:)

You can change the default prompts with my FancyPrompt plugin. Here's how I actually have my prompt (code is slightly different to show off nesting). It may look like "ugh", but it's actually really nice when you're in the driver's seat.