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

Re: postfix dereference syntax

Thread Previous | Thread Next
From:
Darin McBride
Date:
August 16, 2013 04:27
Subject:
Re: postfix dereference syntax
Message ID:
2185681.EZynZJXS4V@naboo
On Thursday August 15 2013 7:04:53 PM demerphq wrote:
> On 15 August 2013 18:12, Darin McBride <dmcbride@cpan.org> 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

You can, but your point is already moot ;)

$ denotes scalar.

But $foo->bar(baz => 3) ... does not give you a scalar.  Well, it might not.  
Depends on what's on the LHS of the =, and how the bar method is implemented.  
Might be void.  Might be a list.  Won't be a hash.

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

Yes, and that works for you.  However, perl isn't just for you ;)

> Now, you could argue that
> 
>   $foo->@* = (1,2,3,4);
> 
> puts the @* in the right place, and that
> 
>   @{$foo} = (1,2,3,4);

Nope, I don't argue either one.  The way I think is obviously different from 
you.  You're focused on the sigil.  I'm focused on order of operations, 
because I already know the sigil doesn't always tell me what I need to know, 
or what I care about.  Right now, I treat @{...} or %{...} as exceptions to 
that.  And you treat method calls as an exception to the way you think.  
Neither one is right or wrong, both are, I think, valid.  It's whatever makes 
the syntax "stick" in our brains.

[elided further description of how you think]

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

This is already true.

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

It will break *your* expectations.  But we already have that.  That you don't 
want *another* breakage, that's fair.  I happen to desire differently.  Not 
that my vote carries much weight, it's simply there.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About