in reply to Reading session data

I rarely use the old $$ syntax these days so I would do this:

use strict; use warnings; use Data::Dumper; my $session_data = { azuread => { login_info => { roles => [ 'Medewerkers', 'etm' ] } } }; print Dumper $$session_data{azuread}{login_info}{roles}; # Like you ha +d print $session_data->{azuread}{login_info}{roles}[0] . "\n";

It just makes the dereferencing easier to me. See also perldsc for more general info on this.


🦛

Replies are listed 'Best First'.
Re^2: Reading session data
by Bod (Parson) on Jun 30, 2023 at 19:58 UTC
    I rarely use the old $$ syntax these days

    It's amazing how quickly we change.

    I used to always use the 'old' syntax on the rare occasion that I attempted to use references. That was until a few people in The Monastery explained references in a way that made them finally click, and someone showed me the 'modern' syntax. I now use references regularly and always use the modern syntax.

    Recently I looked at a bit of my own code from a while ago and it took me a while to work out what was going on thanks to $$!

    hippo - you say you rarely use the old syntax. That implies that occasionally you do. Is there any situation where the 'old' syntax is preferable or even required?

      Is there any situation where the 'old' syntax is preferable or even required?

      It is not required for hashrefs like this but obviously you can't use the normal arrow to dereference things where there are no components. So, if you have a scalar reference the only ways to dereference that are with a $$ or using postfix dereference. In such situations I much prefer the $$ for clarity. In fact I've just tried this example to illustrate and it won't even compile with the postfix deref line uncommented (error is $* is no longer supported as of Perl 5.30).

      #!/usr/bin/env perl use strict; use warnings; use feature 'say'; my $foo = 'some string'; my $ref = \$foo; say "Deref with \$\$: $$ref"; # Uncomment next line for compilation error - why? #say "Postfix deref: $ref->$*";

      Perhaps someone who likes/uses postfix deref can explain where the compilation error comes from and how to fix it. As for me, I'm quite happy with $$ in these situations.

      See also I use postfix dereferencing ... for various comments on how wonderful/terrible postfix dereferencing is.


      🦛

        G'day hippo,

        "Perhaps someone who likes/uses postfix deref can explain where the compilation error comes from and how to fix it."

        The problem revolves around the version of Perl being used, the feature bundle loaded, and additional features requested. Here's some examples:

        v5.36 with full feature bundle
        $ perl -E 'say $^V; my $x = "xyz"; my $r = \$x; say "PFDR: $r->$*";' v5.36.0 PFDR: xyz
        v5.36 with no feature bundle
        $ perl -e 'print $^V; my $x = "xyz"; my $r = \$x; print "PFDR: $r->$*" +;' $* is no longer supported as of Perl 5.30 at -e line 1.
        v5.22 with default :5.22 feature bundle
        $ perl -e 'use v5.22; say $^V; my $x = "xyz"; my $r = \$x; say "PFDR: +$r->$*";' $* is no longer supported as of Perl 5.30 at -e line 1.
        v5.22 with default :5.22 feature bundle plus "postderef" feature
        $ perl -e 'use v5.22; use feature "postderef"; say $^V; my $x = "xyz"; + my $r = \$x; say "PFDR: $r->$*";' $* is no longer supported as of Perl 5.30 at -e line 1.
        v5.22 with default :5.22 feature bundle plus "postderef" feature (dereferencing outside of quotes)
        $ perl -e 'use v5.22; use feature "postderef"; say $^V; my $x = "xyz"; + my $r = \$x; my $y = $r->$*; say "PFDR: $y";' v5.36.0 PFDR: xyz
        v5.22 with default :5.22 feature bundle plus "postderef_qq" feature
        $ perl -e 'use v5.22; use feature "postderef_qq"; say $^V; my $x = "xy +z"; my $r = \$x; say "PFDR: $r->$*";' v5.36.0 PFDR: xyz
        v5.24 with default :5.24 feature bundle
        $ perl -e 'use v5.24; say $^V; my $x = "xyz"; my $r = \$x; say "PFDR: +$r->$*";' v5.36.0 PFDR: xyz

        I couldn't see it specifically documented anywhere but 'use feature "postderef_qq";' seems to imply 'use feature "postderef";'. This is borne out by my own tests (in particular, see the "v5.22" tests above) and documentation of feature bundles that include postderef_qq do not also include postderef.
        [I have a niggling feeling that I did see such documentation a long time ago. If someone locates it, please share. Thankyou.]

        Some relevant documentation links (in no particular order):

        — Ken

      G'day Bod,

      It hadn't occurred to me when reading earlier posts referring to "old syntax", but your use of "modern syntax" made me wonder how much older $$hashref{key} was compared to $hashref->{key}.

      The oldest Perl version available via the online "Perldoc Browser" is for "Perl 5.005". Poking around in various parts of that (perlop, perldsc, and others) I see both forms being used without any mention of one being newer. I'm happy to be proven wrong, but I rather suspect that both have been available since Perl 5.000.

      Without the arrow (dereferencing) operator, it's easy to make mistakes, especially with complex data structures. This is discussed in "5.005: perlref: Using References"; this information is retained in "5.36.1: perlref: Using References".

      Except in the simplest of cases, I'll always prefer the $hashref->{key} form, as I find it both easier to read and less error-prone. I can't think of any situation where the $$hashref{key} form is "required".

      In closing, it's probably worth noting "Postfix Dereference Syntax" and "Postfix Reference Slicing". These are newer syntaxes. I prefer them; I acknowledge that others don't. There's an example of the former in my reply to the OP.

      — Ken

        I rather suspect that both have been available since Perl 5.000

        You could well be right. The "old" label is more referring to when it was in more common use. Back in the day it was everywhere and if that's what you read then that's what you write. I guess the more that I developed as a Perl programmer the more I dealt with complex data structures and the ever more unwieldy the old syntax became. No idea if that's a general thing or specific to me but it's the most likely reason I can see looking back.

        Except in the simplest of cases, I'll always prefer the $hashref->{key} form, as I find it both easier to read and less error-prone. I can't think of any situation where the $$hashref{key} form is "required".

        Completely agree on this.


        🦛

Re^2: Reading session data
by PeterKaagman (Beadle) on Jun 30, 2023 at 07:14 UTC

    Old syntax :D Must be getting old. But then again, I do remember the introduction of Turbo Pascal (with objects). Or was it called Borland Pascal at that time already :D

    But... Thanks, that did actually works. Funny thing is that even the $$ syntax works just fine. Don't really know how I was goofing yesterday.