in reply to Re^2: Experimental features: autoderef vs postfix deref
in thread Experimental features: autoderef vs postfix deref

Why is use 5.024 'a pain to enable'?

Because I'm currently on 5.18; one of my clients is on 5.14 and another on 5.10.

Because I'd have to remember which client's behalf I'm programming on; which version that client uses; which 'feeechers' that version supports; which 'mis-feechers' that version has dropped.

And then go through the whole damn game again when they decide to upgrade; and have to back out and replace the stuff that's 'gone away'.

Life's too short to ripple in the wind of every vanity project p5p allows through.

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.
I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!
  • Comment on Re^3: Experimental features: autoderef vs postfix deref

Replies are listed 'Best First'.
Re^4: Experimental features: autoderef vs postfix deref
by Anonymous Monk on Jul 12, 2015 at 16:12 UTC
    Because I'm currently on 5.18; one of my clients is on 5.14 and another on 5.10.
    So Perl shouldn't get new features just because of your clients. Got it.
[reply]
      So Perl shouldn't get new features just because of your clients. Got it.

      What glib nonsense.

      I'd like perl to get some new functionality. But it'd be nice if:

      1. it was something worth having;

        Not just another because-I-can, vanity project.

      2. it was something that was actually new;

        not just a pointless alternative to something that has always been there.

      3. came with some level of guarantee that it had been thought through and was likely to stay;

        not some hair-brain here-today, gone-tomorrow experiment.

      4. Came as a fully integrated part of the language;

        not something they have so little faith in, they hide it behind a pragma, so that they can throw it away when it inevitably goes wrong, and blame the fall out on those mug enough to have made use of it.

      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.
      I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!
[reply]

        Re: your points a and b, among the new features of interest to me, such as given/when, I think there was a real demand (beyond my own). Even our and state make sense, despite being alternatives to things already there. Also, while say is not of interest to me, I do think there was a real demand for it.

        Re: your point c. Smart Match was not well thought out. It was too magical. Even last year there was much disagreement over a saner Smart Match.

        given/when's down fall was being dependent on Smart Match. Otherwise, I like how it was designed. (FWIW, I never ran in to the problem cases that caused Smart Match to break, despite making good (implicit) use of it via given/when.)

        Re: your point d. My understanding for use of the feature pragma is to avoid backwards compatibility problems. For me, it's rare I have to worry about. for example, our breaking a Perl program, but I am aware of the possibility. Perhaps the version form of use would be a better choice than feature, but at least a compile error on the use statement is (usually) clearer than one deep in the code.

[reply]

In Section Seekers of Perl Wisdom