Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Is auto-dereferencing worth forcing upgrades to newer versions of Perl?

by boftx (Chaplain)
on Aug 15, 2013 at 12:22 UTC ( #1049573=perlmeditation: print w/ replies, xml ) Need Help??

I was reading the docs for splice recently and came across this:

Starting with Perl 5.14, splice can take a scalar EXPR, which must hold a reference to an unblessed array. The argument will be dereferenced automatically. This aspect of splice is considered highly experimental. The exact behaviour may change in a future version of Perl.

To avoid confusing would-be users of your code who are running earlier versions of Perl with mysterious syntax errors, put this sort of thing at the top of your file to signal that your code will work only on Perls of a recent vintage:

use 5.014; # so push/pop/etc work on scalars (experimental)

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"? I have never had a problem using @{$foo} when using splice (or push or pop or anything else expecting an array or list) on an array reference. Yes, the old syntax still works just fine, but if I want to use a module that has the newer syntax I now have to load a newer version of Perl.

I doubt that I will ever use this new syntax unless I am convinced that 99% of the Perl universe will support it. Simply put, if it ain't broke, don't ..., errr, fix it.

Disclaimer: until quite recently I had to work with Perl 5.8.8 the vast majority of the time and only rarely saw 5.10. Consequently I write code to run on 5.8.8 and hope that new modules will load on it. (If you ever need an excuse for a long lunch break install Dist::Zilla on 5.8.8.)

Comment on Is auto-dereferencing worth forcing upgrades to newer versions of Perl?
Select or Download Code
Re: Is auto-dereferencing worth forcing upgrades to newer versions of Perl? (no)
by Anonymous Monk on Aug 15, 2013 at 13:13 UTC
Re: Is auto-dereferencing worth forcing upgrades to newer versions of Perl?
by sundialsvc4 (Monsignor) on Aug 15, 2013 at 13:40 UTC

    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
Re: Is auto-dereferencing worth forcing upgrades to newer versions of Perl?
by tobyink (Abbot) on Aug 15, 2013 at 13:49 UTC

    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?!)

    package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name
      (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"
Re: Is auto-dereferencing worth forcing upgrades to newer versions of Perl?
by BrowserUk (Pope) on Aug 15, 2013 at 14:25 UTC

    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.


    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.
Re: Is auto-dereferencing worth forcing upgrades to newer versions of Perl?
by ikegami (Pope) on Aug 15, 2013 at 17:17 UTC
    No. It's doesn't work on all arrays and hashes, so I don't use it.
Re: Is auto-dereferencing worth forcing upgrades to newer versions of Perl?
by chromatic (Archbishop) on Aug 15, 2013 at 17:41 UTC

    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.

Re: Is auto-dereferencing worth forcing upgrades to newer versions of Perl?
by xdg (Monsignor) on Aug 19, 2013 at 21:15 UTC
    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

    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.
      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.
        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.

        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?

Re: Is auto-dereferencing worth forcing upgrades to newer versions of Perl?
by boftx (Chaplain) on Aug 24, 2013 at 05:01 UTC

    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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://1049573]
Approved by marto
Front-paged by Old_Gray_Bear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (11)
As of 2014-09-17 19:06 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (95 votes), past polls