Re: use feature 'postderef'; # Postfix Dereference Syntax is coming in 5.20 (++)

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

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

[shmem]

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.

[tye]

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

[shmem]

Ah, @* looking like a global variable, I can see that objection.

No. No!

1. My concern is that the @* %* $* constructs blur the lines between operators, sigils and special variables, which is not about globalness or localization, but about language.
2. I am with demerphq on that: It breaks the original model of sigils completely. And more so if the thingy were just a blank @ sign.

As for your examples: what BrowserUk wrote. I prefer the notation

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

because I can read it immediately: a list of variables (my( $state, $zip )) get assigned a list context dereference of soemthing returned by a function call which happens to be a hash ref, and the returned values are accessed with the keys 'state' and 'zip'. Note that the first thing is list.

And I deem this

perl -le '%* = (foo => bar); print $*{foo}; @* = qw(foo bar baz); prin
+t $*[1]'

line's result to be two places where to go now and try to forget about perl, perl5, perl6, the Nikolaus Sieht Alles and whatever else rests heavily on my mind.

[BrowserUk]

Ignoring the dubious nature of immediately flattening a returned array ref to an array, how is:

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

clearer than:

my @got = @{ 
    ExactlyWhatThisReturns( $exactly, $what, $it, $is, $based, $on ) 
};

.

Or this mess:

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

Clearer than this:

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

But I guess these things are in the eye of the beholder.

[ikegami]

But I'd be happy to have the '*' dropped so long as that doesn't introduce parsing difficulties

I think that sentiment is universal. IIRC, the only reason * was used was because not using it would cause parsing difficulties.