G'day WaywardCode,

'... "your code will adhere to strict and warnings no matter what."'

My general recommendation is that you should start all code with those two pragmata. I see not having to always type them as a good thing.

Having said that, the article to which you linked has a number of examples of no. I'm not aware of any reason why you couldn't use that on the rare occasions that you don't want those pragmata.

I would strongly suggest that you only turn off parts of the functionality in a limited lexical scope. Perhaps something like:

my @punctuation_chars;
{
    no warnings 'qw';
    @punctuation_chars = qw{. , ; :};
}
[download]

My general recommendation is that you should start all code with those two pragmata.

Before I am too misunderstood, let me be clear that I agree with the recommendation. I disagree with flipping the defaults that have been in place for decades and telling people code which doesn't work under the new defaults is bad code.

Forget strict, look at what they are proposing with changing the syntax for prototypes. Are you telling me it's impossible to add signatures to the language without changing prototypes? I don't buy that. It might not come out as pretty, but for a language as old as perl, compatible is worth more than pretty. It boggles my mind that they call out postfix dereferencing as a benefit of perl7 in the p7 announcement post, since that doesn't need any feature flags in perl today:

perl -e '$x = [1,2,3]; print $x->@*'

...which makes it a great example of how you can innovate in the language while respecting what it already is.

I never understood why people prefer this ugly postfix syntax over autoboxing methods

${nested}{arrayref}->push(4)

is certainly more readable and shorter than

push @{ ${nested}{arrayref} }, 4

or

push ${nested}{arrayref}->@*, 4

And ->@* should be aliased to ->list or ->arr

Perl 4 started as "bash on steroids", it immediately convinced Sysops to have a better designed language with sed and awk semantics included.

But today's ubiquitous language is JavaScript.

The strategy should be to aim at a "JS on steroids".

And JS has autoboxing.

See also autobox on CPAN.

Autoboxing could be a killer feature when marketing v7 or v8 as more readable advancements.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

Update

And please don't tell me it's not possible to fix the speed penalty with special opcodes for a handful of built in methods.

Again, they said that no strict and no warnings are still possible.

The same for use v5.10.0

So no "no matter what."

If Perl 7 defaults help reducing the copy and paste boilerplate from Perl 4 I'm full for it.

Guacamole is Sawyers private project, it'll have to prove itself.

Disclaimer: I'm not involved in the decision making and have no behind the scene insight.

Just interested in a fair and sober discussion.

> if that disqualifies my thoughts here so be it.

It doesn't disqualify you.

One has to be aware that this board is full of trolls and sockpuppets.

Considering the post history helps.

You are speculating about insights into the "leader's" mind and intentions, but we have no insight into yours.

Again, they said that no strict and no warnings are still possible.

Reverting the new defaults is possible for v7, but they explicitly said it would not necessarily be true for v8. If Perl resumes its pre-5 version pace, that's only a few years away. Even if reverting the defaults remains possible, the programs where strict and warnings are least convenient are 5-line throw-away programs run in implicit -n or -p loops, where turning them off or saying use vars qw// is just getting in the way for no benefit. For one-liners, it could mean the difference between using Perl and not bothering. I claim (and don't appear to be alone, looking at p5p), the better tradeoff is to put use v7 in a file and get all the new defaults. I already use use v5.20 or whatever in my longer scripts, so it seems totally natural, but I guess according to Sawyer almost nobody does this.

Re-watching the p7 talk now, again, I really don't like how certain patterns are labelled "bad." The Perl I know does not get overly opinionated on how I write things. These talks bother me enough to crawl out of the woodwork and ask the Monks if I'm wrong to be concerned. Maybe I am wrong.

I don't think that the details are fixed yet, they will be discussed.

And yes, when using the debugger as repl I wouldn't need or want strictures.

But I see the need among teams to be able to enforce an opinionated Perl. (I kept calling this the use anal pragma till I had the idea to Google for "anal perl" ;)

My favored approach is to have "master" pragmas for different use cases.

And like I already said, my gut feeling tells me that something like use v7 will be the first solution, if only because they don't have that much time for fancier but riskier approaches.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}