A new experimental feature has made it into perl, Postfix Dereference Syntax. The idea appeared Postfix, whole-object dereference operators in 2000 .

It popped up a few months ago and made it into a perl release in october

And today ikegami updated Mini-Tutorial: Dereferencing Syntax and I learned of it

$r = \@a; @b = $r->@*; # equivalent to @$r or @{ $r } $r = [ 1, [ 2, 3 ], 4 ]; $r->[1]->@*; # equivalent to @{ $r->[1] }

perl5190delta
perl5191delta
perl5192delta
perl5193delta
perl5194delta
perl5195delta
perl5196delta
https://metacpan.org/pod/release/BINGOS/perl-5.19.6/pod/perltrap.pod#JavaScript-Traps

Gotta remember to keep checking those deltas :)

Comment on use feature 'postderef'; # Postfix Dereference Syntax is coming in 5.20
Download Code
Re: use feature 'postderef'; # Postfix Dereference Syntax is coming in 5.20
by BrowserUk (Pope) on Nov 23, 2013 at 09:44 UTC

    Just one question: Why?

    It's no less characters; it's not clearer; it's not consistent with anything. A completely pointless addition.


    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.
      Seems like the feature is for its own sake.
      I find the current syntax ugly and not readable:
      @{ $ref1->[0]{a} }

      Unfortunatelly, I do not find the new syntax any better. Was there any discussion? Any other options? Like $ref%-> or $ref-><ARRAY> or $ref->>% or whatever?

      لսႽ ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ

        1) if there are links, explore them :) 2) make links obviou 3) hi

        Basically, rjbs/d.golden really wanted it

        I find the current syntax ugly and not readable:

        Weird isn't it how differently people perceive particular syntaxes. I find the (long form) dereference syntaxes completely consistent and eminently readable (provided they are formatted correctly; which is short-hand for saying: the way I do it :)

        • ${ <thing> }: reference thing as a scalar.
        • @{ <thing> }: reference thing as an array.
        • %{ <thing> }: reference thing as a hash.

        The internal whitespace around thing is imperative IMO, and with it, it is (I find it) totally clear, concise and consistent. The three holy Cs of syntax.

        Personally, I would much rather have seen the short-forms ($$ref, @$ref & %$ref) removed than have another, less concise, less orthogonal, less consistent, less in-keeping-with syntax, added.

        Hm. That last part isn't quite right; let me try that again.

        1. Pointlessly more verbose.
        2. Totally arbitrary.
        3. Utterly inconsistent (with anything).
        4. Confused and confusing.
        5. Completely out of keeping.
        6. Muddled and muddling.
        7. Like fitting a wing mirror to your garden shed.

        Simply the pointless, capricious, because-we-can assertion of the ability to foist whimsy on us muggles. Of course, no one has to use it; but some will, and thus the damage is done.

        In short, exactly what has gone wrong with p5p for the last few years.


        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 share same opinion, I dislike this new feature...

      pity there's no voting booth where I can raise my '--' vote...

      Because it makes (some) code easier to read left-to-right, with no mental notes to figure out what is being dereferenced later on. It's really that simple.
      --
      A math joke: r = | |csc(θ)|+|sec(θ)| |-| |csc(θ)|-|sec(θ)| |
        easier to read left-to-right

        In the absence of evidence, opinion is ...


        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.
      From the documentation (one of the links in the parent):
        This syntax allows dereferencing to be written and read entirely left-to-right.
      Which is something I haven't paid attention to. I'd be willing to give this a try.
Re: use feature 'postderef'; # Postfix Dereference Syntax is coming in 5.20
by Anonymous Monk on Nov 23, 2013 at 10:55 UTC
    What, is the second arrow necessary in $r->[1]->@*?
      I'll translate for you
      my @in = ( 2, 3 ); my @out = ( 1, \@in, 4 ); my $r = \@out; $r = [ 1, [ 2, 3 ], 4 ]; $r->[1]->@*; # equivalent to @{ $r->[1] } # equivalent to @{ $out[1] } # equivalent to @{ \@in }
        or $r->1->flatten
        How does that answers if $r->[1]@* is valid?
Re: use feature 'postderef'; # Postfix Dereference Syntax is coming in 5.20
by davido (Archbishop) on Nov 23, 2013 at 18:21 UTC

    This is an idea that sounds good in principle, and that is destined to turn out not so good. Problems:

    • Additional complexity introduced to the Perl code base will undoubtedly lead to a new round of bug-fixes.
    • A new syntax that will begin to creep into modules and new code that push forward the minimum Perl version without significant benefit.
    • A new set of special cases. I can see it now in Intermediate Perl: "You may omit the -> operator between subscripts, but not between a reference and its flattener
    • If @{ $aref->[1] } is ugly, is $aref->[1]->@* prettier? At least the first seems mostly symmetrical, and visually distinctive. And it has the benefit of putting the most important thing first; we're generating a list. Beauty is in the eye of the beholder, but you would have to be an alien to find more beauty in the new construct than in the symmetry of the old one. Why do we need to put the most important part at the end? Discomforting, it is.
    • It doesn't make simple things easy, or hard things possible. And it really doesn't make impossible things possible. The barrier to entry into Perl syntax really ought to be, "Does it make hard things possible? Does it at least make simple things easier?"

    TIMTOWTDI doesn't mean we need to add every imaginable syntactic alternative.

    Extended bracketed character classes.... now that is a feature that made hard things possible, and well worth the round of bug patching it initiated. In some cases, it may even be worth bumping up the minimum Perl version number of an application or module. // and //= were also slam dunks for making simple things easy and a little more efficient. say..., ok, great for perl -E one-liners, and in code that already needs a sufficiently new version of Perl for other reasons. fc: Absolutely; it makes hard things possible. s///r, for sure. It makes simple things easy.


    Dave

Re: use feature 'postderef'; # Postfix Dereference Syntax is coming in 5.20 so, see you at 5.26 when its removed
by Your Mother (Canon) on Nov 24, 2013 at 01:42 UTC

    DO NOT WANT

      > DO NOT WANT

      Watching your mother regressing to baby talk...

      ... one of the saddest moments in life! : (

      Cheers Rolf

      ( addicted to the Perl Programming Language)

        One may exhaust ones entire continuance to vet bits from here to the DARPA boot files elucidating tittles and jots majuscule, miniscule, uncial, fractious, and farcical. Be the point of the elevation chromatic, and taken as given a statistical assurance one or more of the negotiating parties are tritanopic, and declination is the doom, the clime may behoove forgoing the staid common law designations by RFC, PDQ, and aye, even quid pro quo, resorting, nay, resounding, to the penultimate in efficacious tactics, appeal by Interwebs lingua franca, in quentiam.

Re: use feature 'postderef'; # Postfix Dereference Syntax is coming in 5.20
by sundialsvc4 (Abbot) on Nov 24, 2013 at 15:48 UTC

    Exactly so:   this “fee-chur” is gratuitously incompatible.   A language truly does not need six different ways to write the same thing ... which are not “very obvious shortcuts” to the one (or so) “commonly already-accepted ways to do say it.”   If I stumble-upon some new bit of syntax and have to figure it out, I don’t want to discover that it’s just another way to say what has already been said.   I want it to be a feature.   I want it to let me do what has never been possible before ... and for that to be something that I actually (desperately) need to do.   Otherwise, what exactly have you done for me lately ... except to give me another test-case to write?

      Wowwow! If the Prince of Gratuitous Punctuation is against it, it MUST be a bad idea!
        :-D   Guilty as charged.
Re: use feature 'postderef'; # Postfix Dereference Syntax is coming in 5.20
by einhverfr (Pilgrim) on Nov 25, 2013 at 07:27 UTC

    I don't think this is a good syntax. I would humbly suggest a better syntax is actually a new operator. Something like this:

    my @array \= $arrayref;

    This would be the exact opposite of what happens when you reverse the order of the = and \. I.e. you can already

    my @array =\$arrayref;

    This would just reverse the process.

      I don't think this is a good syntax. I would humbly suggest a better syntax is actually a new operator. Something like this:

      But that does so much less than the proposed syntax, also it confuses assignment with dereferencing (dereferencing doesn't imply assignment)

        Ok, this is a fair concern. The question is what sort of syntax would work when, say, passing in an argument to a function. One could have implicit assignments in a unitary left hand operator for example, something like:

        my $foo = somefunc(\= $bar);

        This would be contextually equivalent to %$bar or @$bar depending on what $bar references. The idea would be it means "what ___ references" and that gets coerced into a list or array after that point. Of course in this context, it would be coerced into a list (of possibly only one value)...

        In short if the \= operator was overloaded so that it could be either binary or unitary (left-hand), then the problem goes away.

Re: use feature 'postderef'; # Postfix Dereference Syntax is coming in 5.20 (++)
by tye (Cardinal) on Nov 25, 2013 at 21:43 UTC

    Wow, that's a lot of hate for what seems a fairly obvious way of extending the postfix deref mechanisms to be complete using fairly obvious syntax. Especially since these were proposed many, many years ago and I've seen several expressions of a desire for them to actually get implemented and I don't recall any significant complaints about the idea over those many years.

    I personally quite dislike the huge separation between tightly related parts involved in @{ ... }{@keys} when the "..." part can easily spread across multiple lines and involve a quite large number of sequential applications of all manner of postfix deref'ing.

    If these are so bad, then surely ->[$i] and ->{$k} have precisely the same problems and should be dropped so that only ${ ... }... can be used. Which would be ridiculous since I see ->[$i] used a ton more than ${ ... }[$i]. I suspect that even @{ ... } will eventually be mostly replaced by ->@* for reasons similar to why ->[$i] is now so much more common than ${ ... }[$i].

    - tye        

      Wow, that's a lot of hate for what seems a fairly obvious way of extending the postfix deref mechanisms to be complete using fairly obvious syntax. Especially since these were proposed many, many years ago and I've seen several expressions of a desire for them to actually get implemented and I don't recall any significant complaints about the idea over those many years.
      "Hate" is too hard I think. Apart from not all things proposed or wanted being good, it is my own fault not to be aware of that fact - but I specially: well yes, detest the @* %* $* constructs, since they blur the lines between operators, sigils and special variables.
      I personally quite dislike the huge separation between tightly related parts involved in @{ ... }{@keys} when the "..." part can easily spread across multiple lines and involve a quite large number of sequential applications of all manner of postfix deref'ing.

      For me, the obvious solution for convoluted @{ ... } constructs is the introduction of temporary, a.k.a. my variables in the respective scope. This serves the purpose of readability and maintainability far better than new syntactic sugar.

      perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

        Ah, @* looking like a global variable, I can see that objection. The prior proposals I saw used ->@ not ->@*. I didn't mind the addition of the '*' when I saw it (just recently) because it seemed borrowed from Perl 6. But I'd be happy to have the '*' dropped so long as that doesn't introduce parsing difficulties.

        Note that $obj->$* even already had a meaning before this change. However, that meaning was quite useless (since $* is no longer supported).

        Surely there are cases when the introduction of a temporary variable can aid clarity, but I don't think that is universally true and I don't think it should be required (in order to work around the incomplete nature of postfix dereferencing prior to this patch).

        my @got = ExactlyWhatThisReturns( $exactly, $what, $it, $is, $based, $on, )->@*;

        If the routine and each of the variables above have reasonable names, then I think assigning a name to the temporary reference would add absolutely zero clarity.

        Similarly, I think it will quite often be the case that in a construct like:

        my( $state, $zip ) = $user->GetAccount()->GetPriorOrder() ->GetShippingAddress()->@{ 'state', 'zip' };

        having to make up a name for the second-to-last result in the chain would have dubious value in improving clarity (more like negative value).

        - tye        

Re: use feature 'postderef'; # Postfix Dereference Syntax is coming in 5.20
by shmem (Canon) on Nov 26, 2013 at 11:28 UTC

    Is it current policy of p5p now to extend all consistency still existing in perl5 with the statement modifier "except when"?

    perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

      shmem:

      "except when"? No, I think it's more like they're going down the path of "given when" <rimshot/>

      I understand the desire to improve perl, but I don't feel like this particular change offers any benefits. I sincerely hope, though, that it doesn't cause me as much grief as smart match.

      ...roboticus

      When your only tool is a hammer, all problems look like your thumb.

Re: use feature 'postderef'; # Postfix Dereference Syntax is coming in 5.20
by webfiend (Vicar) on Dec 09, 2013 at 17:06 UTC

    It makes some sense to me. My preference has been for the @{ ... } style of dereferencing. That style becomes cumbersome when ... is a large expression. I would hit the end of the expression and bounce back to the start of the block to remind myself what was needed. My workaround for that was to add temporary variables whose only purpose was to make @{ ... } easier to read.

    ...->@* reduces the need for those temporary variables because it allows a clear "treat this thing right here like an array." I don't know if this is better or worse, considering that we've been doing it the other way for years. It's just different. I'll try it, because I am a sucker for syntax.