[Purdue-pm] postfix dereference

[Michael Gribskov]

did purdue-pm discuss this new feature of perl 5.20 already?  See 
http://perltricks.com/article/68/2014/2/13/Cool-new-Perl-feature--postfix-dereferencing 
for some examples, and for some deeper discussion of the why (especially 
the digram in number 3).  There was a lot of discussion, mostly 
negative, when this was announce, for instance 
http://www.perlmonks.org/?node_id=1064016.  The comment by BrowserUK is 
particularly good (below)

    Weird isn't it how differently people perceive particular syntaxes.
    I find the (long form) dereference syntaxes completely consistent
    and eminently readable (provided they are formatted correctly; which
    is short-hand for saying: the way I do it :)

      o ${ <thing> }: reference thing as a scalar.
      o @{ <thing> }: reference thing as an array.
      o %{ <thing> }: reference thing as a hash.

    The internal whitespace around thing is imperative IMO, and with it,
    it is (I find it) totally clear, concise and consistent. The three
    holy Cs of syntax.

    Personally, I would much rather have seen the short-forms
    ($$ref,@$ref&%$ref) removed than have another, less concise, less
    orthogonal, less consistent, less in-keeping-with syntax, added.

    Hm. That last part isn't quite right; let me try that again.

     1. Pointlessly more verbose.
     2. Totally arbitrary.
     3. Utterly inconsistent (with anything).
     4. Confused and confusing.
     5. Completely out of keeping.
     6. Muddled and muddling.
     7. Like fitting a wing mirror to your garden shed.

    Simply the pointless, capricious, because-we-can assertion of the
    ability to foist whimsy on us muggles. Of course, no one has to use
    it; but some will, and thus the damage is done.

    In short, exactly what has gone wrong with p5p for the last few years.


his point is backed up by dmitri who says

         From the documentation (one of the links in the parent):
            /This syntax allows dereferencing to be written and read
            entirely left-to-right./ Which is something I haven't paid attention to. I'd be willing
        to give this a try. 

	[reply] <http://www.perlmonks.org/?parent=1067164;node_id=3333>


A final point, which relates to what we talked about last week, Davido 
says, and I agree

    This is an idea that sounds good in principle, and that is destined
    to turn out not so good. Problems:

      o Additional complexity introduced to the Perl code base will
        undoubtedly lead to a new round of bug-fixes.
      o A new syntax that will begin to creep into modules and new code
        that push forward the minimum Perl version without significant
        benefit.
      o A new set of special cases. I can see it now in_Intermediate
        Perl_: "You may omit the->operator between subscripts, but not
        between a reference and its flattener
      o If@{ $aref->[1] }is ugly, is$aref->[1]->@*prettier? At least the
        first seems mostly symmetrical, and visually distinctive. And it
        has the benefit of putting the most important thing first; we're
        generating a list. Beauty is in the eye of the beholder, but you
        would have to be an alien to find more beauty in the new
        construct than in the symmetry of the old one. Why do we need to
        put the most important part at the end? Discomforting, it is.
      o It doesn't make simple things easy, or hard things possible. And
        it/really/doesn't make impossible things possible. The barrier
        to entry into Perl syntax really ought to be, "Does it make hard
        things possible? Does it at least make simple things easier?"

    TIMTOWTDI doesn't mean we need to add every imaginable syntactic
    alternative.




-- 
Michael Gribskov
Hockmeyer Hall of Structural Biology
Department of Biological Sciences
Purdue University
240 S. Martin Jischke Drive
West Lafayette, IN 47907-1971

gribskov at purdue.edu     vox: 765.494.6933     fax: 765.496.1189
calendar: http://www.google.com/calendar/embed?src=mgribskov%40gmail.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/purdue-pm/attachments/20140717/4fc44453/attachment.html>