There are plenty of good features that are worth upgrading for in 5.14, but this is not one of them.

Even when writing code that requires Perl 5.14, I avoid this new feature, preferring to use an explicit @{} dereference operation.

As chromatic has pointed out before, when combined with the fact that Perl 5.12 allows each, keys and values to work on arrays like they do on hashes, this feature introduces ambiguities. (What happens in blessed arrayrefs which overload hashrefification? Or blessed hashrefs which overload arrayfication? Or blessed scalar refs which overload both?!)

(What happens in blessed arrayrefs which overload hashrefification? Or blessed hashrefs which overload arrayfication? Or blessed scalar refs which overload both?!)

push $blessed_hashref_or_arrayref, ...
results in:
"Not an ARRAY reference" or
"Not an unblessed ARRAY reference"

each $blessed_hashref_or_arrayref
results in:
"Type of argument to each on reference must be unblessed hashref or arrayref"

There are no backwards compatibility concerns. This syntax was a syntax error in earlier versions of Perl. Code written for those older versions will continue to work with no changes.

With that said, this feature interacts poorly with the much more useful 5.12 feature of using each on arrays. I pretend autodereferencing doesn't exist.

It's one of several features added in the 5.12-5.16 flurry of releases that seem intended to steal back some "under active development" limelight, by borrowing stuff from Perl6, that unfortunately were not subjected to Mr.Wall's thoroughness of thinking things through.

Of little practical utility and even less orthogonality, it's another feature that seems destined to languish at the bottom of the toolbox only seeing light of day when golfers are looking to reduce their handicaps.

I feel no. This feature is tiny spec of sugar (for super noobs) , and sugar is no good reason to upgrade :)

If you want a reason to upgrade, better threading/unicode support is what its about.

For the noobs, see references quick reference

http://www.citrusperl.com/, http://www.cavapackager.com/

I have to ask, is it really worth breaking backwards compatibility, that is, forcing an upgrade to a newer version of Perl, by adding this "feature"?

From whose perspective?

Using newer features of any version of Perl in a CPAN module means that some people won't be able to use them until they upgrade. The flip side is that some of these newer features make developing and maintaining code easier.

Volunteers are free to set that trade-off wherever they choose. The line may change over time. Even the Perl module toolchain now only targets v5.8.1, whereas it used to target v5.6 and before that v5.5.

This particular auto-dereference feature is experimental. By definition, that's the sort of thing that using in a library will reduce the number of people who try it. (It may be superseded by more recent p5p discussions about a "postfix dereference" operator. Who knows? That's why we have experiments.)

But compare that to the new s///r feature. That's something that I welcome. For some code I publish, I choose to make v5.14 a minimum because I like coding with that more than I care to support ancient perls. For other libraries, I make a different choice.

But I wouldn't hesitate to make v5.10 a minimum for just about anything general purpose these days. As others make that same decision, the days will be numbered for staying on v5.8.X and expecting the newest CPAN modules to just work.

-xdg

It may be superseded by more recent p5p discussions about a "postfix dereference" operator.

Which would be an even more useless, fad-driven, change-for-change's-sake, distraction to nowhere than auto-dereferencing.

The justifiction for this: @{ $ref } becoming: $ref->@* or $ref->[] (empty brackets) or dog-knows what else is: Blech

I ask you. The technical justifiction is "Blech".

Funnily enough, I agree that this: push @{ $x->{foo}->[0]->m }, $y; is a bit ugly.

But who writes code like that anyway? And what would it mean if they did?

Let's break that mother down:

1. $x is a reference
2. to a hash that has a key 'foo'
3. who's value is an array
4. of objects that have a method 'm'
5. that takes no arguments and returns a reference to an array
6. onto which we need to push values.

Why would anyone invent an api that requires you to call a method to get a reference to an (internal) array onto which we are to push values; rather than just passing the values to be pushed to a method that does it for us?

Yes, I know it is an invented, over-the-top example to make a point.

And that's my point. If you have to use an invented, over-the-top example to justify something; you've failed.

Cos, $x{foo}[0]->push( $y ) is clean, simple and obvious. And it works right now.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Speaking of aesthetics, I find that example ambiguous. It's not obvious to me whether push is a method that just so happens to have the same name as the push keyword (the one which works on arrays) or whether it's an alternate way of writing that keyword. Is that a method which operates on a container (the array) or an object (not really a container)?

In my mind, one of Perl's OO flaws is unnecessarily confusing containers and objects. An object may have containers, but should it be one?

And it works right now.

Not in core, it doesn't. (Though I wish it did.)

But anyway, you're missing (or intentionally misdirecting) the point that the justification is not technical, but aesthetic.

And what do you care? If you don't like a given feature (and there's no global performance cost involved in implementing it in the first place), just don't use it.

Some people like new features and some don't. Some like evolution and some like stability. Fine.

My point was that these are individual decisions to be made by individual developers. Expecting "everyone" or "no one" to use a given feature is unrealistic. There's an adoption curve. It happens. No big deal.

-xdg

_{Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.}

Definitely “not.”

There are millions of lines of Perl source-code in production service, and maintaining seamless compatibility across upgrades is very important.   Adding a fee-chur for no more reason than saving a programmer a couple of flexes of his fingertips on the keyboard .. when there already exists a way to get this done .. is an unwise thing to do, especially when the change is not “source-code obvious.”   Adding a new, convenient operator is okay because older Perl compilers will instantly reject it with a syntax error, with-or-without strict/warnings.   But adding a fee-chur which changes the meaning of existing source code is, in my opinion, a source of pointless grief.   I see no return-on-investment to warrant the greatly increased business risk.

Still want to do it?   Then introduce a use auto_dereference pragma, which only works on (say ...) 5.014 forward.   (The use 5.014; directive can stay, of course, but now it does not have “hidden meaning” that only a perlguts person would be expected to know.)   Now you are declaring, both to Perl and to the future programmers, what you mean.   Importantly, you are now doing it in a way that will generate syntax-errors in older Perls.   (You also presumably can now “bracket” specific sections of code with use/no blocks.)   The programmer gets a “heads up!!” alert to be on the lookout for “specifically, this New Thing,” and older compilers will fall on their face, flagging that particular line of source with its immediately-obvious import as their nose hits the pavement.

I'm pretty sure that strict-or-not, you'll get a compile-time syntax error if you try this on Perls earlier than 5.14. You'd have quite a struggle to find existing Perl code that this change broke.

I don't think it's a good feature, but it's a freeture, not a feeture.

package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name

After reading the replies I am convinced that the proper course of action when writing code that might find its way to CPAN is to adhere to the lowest version of Perl that one is still likely to find in common use. At this point in time that is possibly 5.8.x but arguably 5.10.x might be a reasonable cutoff. (I am not aware of any major hosting provider that still has 5.8.x for a system perl at this time, but ...)

That being said, it should be obvious that when one is writing code that will be used in a private environment where there is full control over which perl is to be used then one should take full advantage of the features that allow for a better product. The question in my OP was aimed at those of us who on occasion (or regularly) contribute to CPAN in the hopes of making life a little bit easier for someone else as a way of saying "Thank you" to those who have gone before us.

Thank you all for your contributions to this discussion.