develooper Front page | perl.perl5.porters | Postings from August 2013

Re: postfix dereference syntax

Thread Previous | Thread Next
August 15, 2013 17:05
Re: postfix dereference syntax
Message ID:
On 15 August 2013 18:12, Darin McBride <> wrote:
> The @{...} syntax forces
> me to mentally go back to the beginning (or mentally note what's at the
> beginning) just to figure out what's going on.

I could turn your argument on its head. When I am assigning I want the
type of return (scalar or list) to be as close to the assignment
operator as possible so it is obvious what is being returned from the
expression (a list or a scalar). If the @* is at the end of the line,
then it is as far as possible from the place I will be looking at.
Now, you could argue that

  $foo->@* = (1,2,3,4);

puts the @* in the right place, and that

  @{$foo} = (1,2,3,4);

puts the @ in the wrong place (at the start of the expression) instead
of next to the assignment operator.

But you could equally argue that

  $thing= @$foo;

puts the @ in the right place, and that

  $thing= $foo->@*;

puts it in the wrong place.

My point with this is any argument about the "rightness" of the @
being at one end of the expression or the other will fall down in as
many places as it stands up, and if I switch which end, ill reverse
the places where it falls down or stands up. So there is no right
answer here. Sometimes a postfix operator would make more sense than a
prefix operator sometimes not. (It has not escaped me that this is
decent argument for allowing both forms.)

This aside I think there is a real problem with this proposal. It
breaks the original model of sigils completely. IMO sigils are hard
enough that completely breaking the original intent is not helpful, no
matter how sweet your tooth is for the syntactic sugar it offers.

My understanding of the Perl5 sigils is that they are meant to denote
the type of result that will be _returned_*.

We write:

   $thing= $foo[1];

and not

   $thing= @foo[1];

because the former tells us we are getting back a scalar. The latter
says we are getting back a list.

From this point of view you could argue that the postfix form disrupts
this pattern:

my @things= $foo->@*;

So, now, the $ no longer can be relied to refer to a "scalar", it
might be a scalar, it might not.

This IMO is a real stumbling block for this proposal. It break well
established and documented expectations for what seems to be little

* I looked for documentation to back this up, and the best I could
find was in perlfaq4. I suspect that it is better documented in one of
the Perl books by Larry.

perlfaq4: What is the difference between $array[1] and @array[1]?

The difference is the sigil, that special character in front of the
array name. The C<$> sigil means "exactly one item", while the C<@>
sigil means "zero or more items". The C<$> gets you a single scalar,
while the C<@> gets you a list.

The confusion arises because people incorrectly assume that the sigil
denotes the variable type.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About