Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

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

by tye (Cardinal)
on Nov 25, 2013 at 21:43 UTC ( #1064312=note: print w/ replies, xml ) Need Help??


in reply to use feature 'postderef'; # Postfix Dereference Syntax is coming in 5.20

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        


Comment on Re: use feature 'postderef'; # Postfix Dereference Syntax is coming in 5.20 (++)
Select or Download Code
Re^2: use feature 'postderef'; # Postfix Dereference Syntax is coming in 5.20 (++)
by shmem (Canon) on Nov 26, 2013 at 11:51 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.
    "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        

        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.


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

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

        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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1064312]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (6)
As of 2014-12-21 18:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (106 votes), past polls