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


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 (Saint) 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!

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

[reply]

In Section Meditations