RE: Postfix, whole-object dereference operators

[japhy]

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 }.

[tye]

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:

    ${${$obj->Method()}{key}}[0];

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();

does

    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.

[cwest]

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:

%{$ref->[0]->{param}->[1]->{name}};

and you can't do this:

%$ref->[0]->{param}->[1]->{name};

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.

Perhaps:

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}};

--
Casey

[japhy]

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} }

[japhy]

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