http://www.perlmonks.org?node_id=1064433


in reply to Re^3: use feature 'postderef'; # Postfix Dereference Syntax is coming in 5.20 (*)
in thread use feature 'postderef'; # Postfix Dereference Syntax is coming in 5.20

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' };

[download]
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]'

[download]
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'

Replies are listed 'Best First'.
Re^5: use feature 'postderef'; # Postfix Dereference Syntax is coming in 5.20 (sigils)
by tye (Sage) on Nov 26, 2013 at 20:31 UTC
    Ah, @* looking like a global variable, I can see that objection.

    No. No!

    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.

    I said "global variable" not to emphasize "global" (don't be so quick to assume I'm not agreeing with you?). I see the syntax having a strong visual similarity to a (global or "special") variable and find this similarity to be a problem (same as you). I don't like blurring the lines between what looks like a type of variable and what is a syntax used for dereferencing.

    I don't see how it blurs any lines related to operators, though. Unless you somehow consider something like ->{ ... } an operator. -> is an operator. ->[ is something more than that for which I don't have a particularly good name. ->[ ... ] is "syntax" or a "construct".

    So, clearly, we need to drop the % (modulo) operator since we all know that % is supposed to be a sigil, and we mustn't blur the lines between sigils and operators. Same goes for & and *, by the way. ** looks like a glob named '*' so certainly must not be used as an operator. %= looks like a special hash.

    Actually, %= is a global hash. It is also the modulo-assignment operator. 

     > say '%= = 0..9; $k = %=; $k %= %=;'
Argument "4/8" isn't numeric in modulus (%)
Argument "4/8" isn't numeric in modulus (%)
0

    [download]

    I find ->@* much less worrying than the above as the required prefix (->) is so much more explicit and visible. I'm not sure how I'd feel about the -> being optional in some cases (maybe it already is?).

    And the mentioned part of demerphq's argument that you linked to:

    my @things= $foo->@*;

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

    Complains about a guarantee that already isn't assured: 

    my @things = $scalar->fetch_all_the_things();

    [download]

    so I find that argument quite unconvincing.

    - tye        

[reply]
[d/l]
[select]

      So, clearly, we need to drop the % (modulo) operator since we all know that % is supposed to be a sigil, and we mustn't blur the lines between sigils and operators. Same goes for & and *, by the way. ** looks like a glob named '*' so certainly must not be used as an operator. %= looks like a special hash.

      Actually, %= is a global hash. It is also the modulo-assignment operator. 

       > say '%= = 0..9; $k = %=; $k %= %=;'
Argument "4/8" isn't numeric in modulus (%)
Argument "4/8" isn't numeric in modulus (%)
0

      [download]

      I find ->@* much less worrying than the above as the required prefix (->) is so much more explicit and visible. I'm not sure how I'd feel about the -> being optional in some cases (maybe it already is?).

      Excellent example. Any variable =~ /^\Q$@%\E\W/ is, by convention, a special variable, and those that happen to be plain vanilla scalars, arrays or hashes currently, are special variable candidates as long as I know Perl books; and those should not be used as variables because:

      • no guarantee exists that those will not have a special meaning in a future release of perl
      • they look special and may be confused with operators and are confusing as part of their specialness

      So - no, we need not drop the modulo operator - me must not use "%=" as a hash! And this 

      $\ = "\n";
*{'@*'} = sub { @{$_[0]} };
bless my $ref = [ qw(foo bar baz) ];

$method = '@*';

print for $ref->$method;
__END__
foo
bar
baz

      [download]

      while it works without use feature 'postderef', is plain weird - implementing the content of $method as a literal not less so.

      And the mentioned part of demerphq's argument that you linked to: 

          my @things= $foo->@*;

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

      [download]
      Complains about a guarantee that already isn't assured: 
      my @things = $scalar->fetch_all_the_things();

      [download]
      so I find that argument quite unconvincing.

      Come on, $scalar->fetch_all_the_things(); is a method call, and objects are just references held in scalars, just like scalar, hash and array references. But your example brings up my next objection: $ref->@* looks like $ref being an object. Is it? should it be? In my humble opinion: no. There's already enough overhead in each perl run.
      Are we going in that direction, making everything into objects?

      perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
[reply]
[d/l]
[select]
Re^5: use feature 'postderef'; # Postfix Dereference Syntax is coming in 5.20 (*)
by ikegami (Patriarch) on Nov 29, 2013 at 15:50 UTC

    I am with demerphq on that: It breaks the original model of sigils completely.

    Except demerphq is mistaken. Perl5 sigils don't denote the type of result that will be returned.

    • @{ ... } evaluates to an array, a list or a scalar.
    • @{ ... }[1,2] evaluates to a list or a scalar.
    • %{ ... }[1,2] evaluates to a list or a scalar.
    • %{ ... } evaluates to a hash, a list or a scalar.
    • *{ ... } returns a scalar (glob).
    • *{ ... }{ARRAY} returns a scalar (reference).
    • &{ ... } can evaluate to a list or a scalar.
    • ${ ... }->() can evaluate to a list or a scalar.

    so

    • @ can evaluate to an array, a list or a scalar.
    • % can evaluate to an hash, a list or a scalar.
    • $ can evaluate to a list or a scalar.
    • & can evaluate to a list or a scalar.
    • * can evaluate to a glob or a reference.

    You already have to locate the end of the expression. Nothing's been broken.

[reply]
[d/l]
[select]
      Except demerphq is mistaken. Perl5 sigils don't denote the type of result that will be returned.

      Of course they do, at least since perl4 patchlevel 36 (or 19 on Atari). The result of the evaluation of an identifier with its sigil may be coerced to something diferent depending on the context in which that evaluation is effective, but the evaluation of an identifier bare of any context depends on its sigil. If that were not the case, sigils would be pointless.

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

        The exception would be method calls.

        $object->foo() # $-sigil, but does this return a scalar?

        [download]

        Obviously this is bracketed as:

        ($object)->foo()

        [download]

        ... so the sigil does make sense: that particular subexpression returns a scalar. However, the expression as a whole could return a list.

        Some people argue that method calls should always return a scalar; if you need to return more than one result, return an arrayref.

        use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name
[reply]
[d/l]
[select]

        The result of the evaluation of an identifier with its sigil may be coerced to something diferent depending on the context in which that evaluation is effective

        That's not how context works at all, but even if you only consider list context, you still have:

        • @{ ... } evaluates to an array or a list.
        • @{ ... }[1,2] evaluates to a list.
        • %{ ... }[1,2] evaluates to a list.
        • %{ ... } evaluates to a hash or a list.
        • *{ ... } returns a scalar (glob).
        • *{ ... }{ARRAY} returns a scalar (reference).
        • &{ ... } can evaluate to a list or a scalar.
        • ${ ... }->() can evaluate to a list or a scalar.

        so in list context,

        • @... can evaluate to an array or a list.
        • %... can evaluate to an hash or a list.
        • $... can evaluate to a list or a scalar.
        • &... can evaluate to a list or a scalar.
        • *... can evaluate to a glob or a reference.

        Of course they do, at least since perl4 patchlevel 36 (or 19 on Atari).

        I can't verify that claim, but I doubt it. At the very least, it hasn't been the case since 5.6 which was released 14 years ago. There is not a single sigil that indicates the type of the value returned.

        the evaluation of an identifier bare of any context depends on its sigil.

        Noone said otherwise. Of course it depends on the sigil. @a is not the same as $a.

        The premise demerphq put forth is that the sigil is an indicator of the type of value to which the sigiled expression evaluates to. That's clearly not the case. You can't break a model that doesn't exist.

[reply]
[d/l]
[select]
      %{ ... }[1,2] evaluates to a list or a scalar.

      That doesn't evaluate to anything, it is a syntax error.

      And the rest of the post is a straw man.

      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.
[reply]
[d/l]

        it is a syntax error.

        Depends on your version of Perl. It's called a index-value slice. It returns key,val,key,val,...

        And the rest of the post is a straw man.

        Showing that sigils don't indicate the type of value returned is not a straw many to disproving that sigils indicate the type of the value returned.

[reply]

In Section Meditations