Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re: Unifying namespaces of @name and $name to simplify dereferencing?

by RonW (Parson)
on Mar 27, 2016 at 22:44 UTC ( #1158915=note: print w/replies, xml ) Need Help??


in reply to Unifying namespaces of @name and $name to simplify dereferencing?

I'm normally too lazy to always type the dereference operator ->

Sounds to me like you are really asking for auto-dereference, so that $a[1] is interpreted as $a->[1]

While auto-magically defining my $name = \@name would simulate something like that, I think it just introduces too many other problems.

Even assuming that the same symbol name is not reused for other types of variables (a good practice in general), is implicit dereferencing a scalar variable really a safe thing to do? If not, then this feature would be setting up Perl beginners for problems when implicit dereferencing needs to be disabled.

Replies are listed 'Best First'.
Re^2: Unifying namespaces of @name and $name to simplify dereferencing?
by LanX (Archbishop) on Mar 27, 2016 at 23:05 UTC
    > While auto-magically defining my $name = \@name would simulate

    It's not only simulating, one has to enforce the control over both namespaces to make it safe and detect conflicts.

    > is implicit dereferencing a scalar variable really a safe thing to do?

    the implicit my for the bound variable guarantees this.

    Many languages do implicit dereferencing, they just can't afford separated namespaces then.

    > If not, then this feature would be setting up Perl beginners for problems when implicit dereferencing needs to be disabled.

    most of this thread is dealing with the question of how to safely blend with "classical" variables. (which wasn't my initial intention)

    My current approach is that a array reference $arr_ref with implicit dereferencing shouldn't allow equally named variables of other types, i.e. if $name[.] := $name->[.] then trying to use $name{} or $name->{} or $name->() in the same scope should fail at compile time, if those variables live in an upper scope they should be hidden in the current scope.

    I have problems to imagine code where the same identifier is used for different types, which shouldn't be better refactored.

    Cheers Rolf
    (addicted to the Perl Programming Language and ☆☆☆☆ :)
    Je suis Charlie!

      I have problems to imagine code where the same identifier is used for different types, which shouldn't be better refactored.

      Yes, this is a problem.

      Unlikely enforcing this would ever become a module, let alone an optional feature of Perl itself. And I don't know if Perl Critic has a rule for this.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (4)
As of 2019-12-15 02:16 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?