Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much

Postfix, whole-object dereference operators

by tye (Sage)
on Jul 21, 2000 at 01:20 UTC ( #23491=note: print w/replies, xml ) Need Help??

in reply to Re: keys function question
in thread keys function question

Okay, so I left off the "Enjoy!" and so ctweten's has gotten more votes than mine. ;)

This discussion has been so short and to the point, I thought I'd add a bit...

I dislike having to use the %{...} syntax as it is hard to read. One solution is:

$ref= $obj->{param}; for( keys %$ref ) { Mung( $ref->{$_} ); }
But what we really need is a post-fix operator that give you the whole hash (or array, or scalar, etc.) from a reference:
my @keys= keys $obj->{param}->%;
This was proposed on perl5-porters a while back but noone has submitted a patch (as far as I know) to implement it. So here is your chance to become famous. Go to the perl5-porters archive and read up on the proposal and you've got a great project for learning Perl guts.

Replies are listed 'Best First'.
RE: Postfix, whole-object dereference operators
by cwest (Friar) on Jul 21, 2000 at 18:03 UTC
    Oh C'mon, I voted you up, now you're winning :-)

    I'll have a few spare tuits comming soon.

    I'll have a look at this, sounds fun!

    I've never hacked Perl guts before but I'm willing to give it a shot.

    print foreach $r->%; print foreach $r->@; print foreach $r->$; print foreach $r->*;
    Enjoy! :-)
RE: Postfix, whole-object dereference operators
by japhy (Canon) on Jul 21, 2000 at 19:11 UTC
    I disagree. Referencing and derefencing should be pre-fix, and if you don't like the SIGIL{} syntax, add whitespace. $foo->\ is silly-looking. \$foo is not. $foo->% also looks silly to me, and if %$foo is too noisy, do %{ $foo }.

      As another noted, the worst case isn't when you have something simple like $foo. Plus, I didn't mention the other postfix dereference operators flavors:

      $obj->Method()->{key}->@[3,7]; $obj->Method()->{lock}->@{"open","close"};
      instead of
      @{$obj->Method()->{key}}[3,7]; %{$obj->Method()->{lock}}{"open","close"};

      I particularly hate the wide separation of the @ and the [3,7] above.

      But you don't have to use it. I agree that taking a reference should be prefix and never proposed (nor saw a proposal for $foo->\. But most of the dereferencing I do is already postfix via -> anyway.

      If you don't like it, you must be typing:

      instead of either of:
      $obj->Method()->{key}->[0]; $obj->Method(){key}[0];
      The added postfix dereference operators just round things out so I can use postfix for more than just getting a single element. Note the nice similarity:
      $obj->Method()->{key}->[1]; # One element. $obj->Method()->{key}->@[1,2]; # Two elements.
      I really doubt I'd write $foo->@, reserving its use for chains of dereferences like above.

      Now, the really whacky thing I'd love to see is the list dereference operator, but that patch is just too much work for the size of audience who can appreciate it. It lets you take multi-dimensional slices:

      $data->@{qw(this that other)}->>@[3,7]->>Method();
      my @ret; for( %{$data}{qw(this that other)} ) { for( @{$_}[3,7] ) { push @ret, $_->Method(); } } return @ret;
      I had a real use for this when I was automating installations of WindowsNT. To make complex decisions about how to partition and format hard disks, I built a big data structure that described tons of details about the current configuration of your hard disks and partitions. This in itself was very handy but I kept wanting to do things like:
      SavePartnSizes( $info->{Disks}->@->>{Partition} ->>@->>@{"Label","SizeMB"} ); #vs. my( @partns, %partnSize ); for my $disk ( @{$info->{Disks}} ) { for my $partn ( @{$disk->{Partition}} ) { push @partns, $partn->{Label}; $partnSize{$partn->{Label}}= $partn->{SizeMB}; } } SavePartnSizes( @partns, @partnSize{@partns} );

      It feels a lot like map.

      OK, enough rambling.

      I think he's directly refering to the situation where you have a few references in a row, particularly in hashes... I too, think this is ugly:
      and you can't do this:
      so, I think it's a gripe about the ugly looks of the syntax. IMHO, I don't mind it, I consider it something like "Variable Encapsulation" in syntax. However, I could see a secondary syntax, as a prefix.


      print foreach HASH $obj->{param}; # or we don't like barewords print foreach 'HASH' $obj->{param}; # or parhaps it's really in a prag +ma use dereference qw/HASH/; print foreach HASH $obj->{param}; # or it stays the same print foreach %{$obj->{param}};
        The pragma would have to be very magical, since it's a waste to return a potentially LONG list, like an array or hash, and functions like each() and keys() and values() and push() and pop() (etc) require ACTUAL hashes or arrays in their first argument, not things RETURNING them.

        As for %{$ref->[0]->{param}->1->{name}} being ugly, ADD WHITESPACE, and REMOVE ARROWS:
        %{ $ref->[0]{param}[1]{name} }
        I've written a preliminary version of this pragma (it's horrible and ugly, by the way).
        use deref; $href = { 1,2,3,4 }; for (sort keys HASH{ $href }) { print "$_ -> $href->{$_}\n"; }
        I'm working on a second one that doesn't require the { }. It's difficult, because I have to parse perl, and pretty much the only language that can parse perl is Perl. I mean, my first version breaks in places like:
        print "This breaks the HASH{} thing.\n"; # becomes print "This breaks the %{} thing.\n";
        I suppose I could run the code through B::Deparse, but that might break parts of it, which would be A Bad Thing. $_="goto+F.print+chop;\n=yhpaj";F1:eval

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://23491]
and not a whimper to be heard...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (8)
As of 2017-10-17 13:20 GMT
Find Nodes?
    Voting Booth?
    My fridge is mostly full of:

    Results (232 votes). Check out past polls.