Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

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

by tye (Cardinal)
on Nov 26, 2013 at 20:31 UTC ( #1064468=note: print w/ replies, xml ) Need Help??


in reply to Re^4: 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!

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

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();

so I find that argument quite unconvincing.

- tye        


Comment on Re^5: use feature 'postderef'; # Postfix Dereference Syntax is coming in 5.20 (sigils)
Select or Download Code
Replies are listed 'Best First'.
Re^6: use feature 'postderef'; # Postfix Dereference Syntax is coming in 5.20 (modulo)
by shmem (Canon) on Nov 27, 2013 at 14:25 UTC

    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

    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

    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.
    Complains about a guarantee that already isn't assured:
    my @things = $scalar->fetch_all_the_things();
    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'

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (12)
As of 2015-07-31 12:54 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The top three priorities of my open tasks are (in descending order of likelihood to be worked on) ...









    Results (277 votes), past polls