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

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.

  • Comment on Re^6: Experimental features: autoderef vs postfix deref

Replies are listed 'Best First'.
Re^7: Experimental features: autoderef vs postfix deref
by BrowserUk (Patriarch) on Jul 13, 2015 at 20:01 UTC
    • such as given/when, I think there was a real demand

      The problem is not that they were added; its that they were added half-baked and have gone away.

    • Smart Match was not well thought out.

      Agreed, but ditto given when.

    • given/when's down fall was being dependent on Smart Match

      Yes.

    • My understanding for use of the feature pragma is to avoid backwards compatibility problems.

      I find this a a justifiction; based on illogical reasoning.

      The premise is that if Perl breaks "backward compatibility"; it will what? Stop people using it because they might have to make occasional changes to their legacy code?

      Eg. Someone somewhere might have a function in their code named 'say'; so if say were added as a new keyword; their code would break.

      Essentially, that is saying that every other user has to do extra work -- use x.xxx or use feature ...; -- in order to prevent the one or two guys out there that are too lazy to rename their say() function.

      And the purpose is what? To retain the patronage of those lazy few? Is that good reasoning?

      No other language I know of is so bound (encumbered) by its history as Perl. And where other languages have made similar concessions to backward compatibility -- Java with its morass of legacy libraries; C++ with it's avoidance of the most suitable keywords for its system library methods, because of conflicts with popular legacy libraries (like Boost) -- it is equally to the detriment of those languages.

    But, by far the most damaging thing is the impermanence of 90%(+?) of the recent new features.

    There are statements above to the effect of: "But postfix deref is okay. It won't go away"; but find anyone who would admit that smart-match was half baked for the first 3 years of its existance; yet even after numerous re-writes ...

    Once, twice, thrice, force, fivce times bitten -- never again. If postfix deref actually simplified or clarified anything; maybe you'd take a punt on it; but (IMO) it doesn't.

    If find the justifictions("Stylistically the circumfix operation is ugly.") for postfix deref utterly specious. For me it is the syntactic equivalent of the form:

    I really, really like you xyz and think that you should be commended and rewarded for your contribution; Not!

    It puts the most important part of the statement at the end; after you've committed hari-kari from boredom plowing through all the details.

    At a glance, this: push @{ $deep_array_ref->[0][0][0][0] }, 4; reads as "push 4 into an array. And at first glance that's all I need to know.

    And when I need to know more, like which array, I know its the bit between @{ and }; all nice and cleanly delineated.

    With this: push $deep_array_ref->[0][0][0][0]->@*, 4; I cannot see the wood for the trees. There's no delineation of the purpose of the statement and the details of its implementation. Its just one big mess of underscores and minus signs and zeros with a splodge on the end.

    It does nothing new; nor simpler; nor cleaner. As such, and given the history, why would anyone take the risk.

    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]
[d/l]
[select]
      push @{ $deep_array_ref->[0][0][0][0] }, 4;

      [download]
      Surely you mean 
      push @{ ${ ${ ${ ${$deep_array_ref}[0] }[0] }[0] }[0] }, 4;

      [download]
      If you don't mean that... I don't know why postderef upsets you so much. It's just like, you know, the rest of that syntax.
[reply]
[d/l]
[select]

        Heh. Too subtle, I guess. Neither of them "got" it. Well, one of them is probably just trolling their (pretend) lack of understanding.

        - tye        

[reply]
        Surely you mean

        Nope. Go look.

[reply]

        ... Surely you mean ... If you don't mean that... I don't know why postderef upsets you so much. It's just like, you know, the rest of that syntax.

        You don't even know whats being discussed? Oh boy

[reply]

In Section Seekers of Perl Wisdom