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

I think that it would make maint a LOT harder (decreased readability). If people already complein about using the same "name" for variables that are related, this would only worsen that. Personally I'd choose an opt-in to make use of this new hypothetical feature a fatal warning :]

my %name;
my @name;

sub name {
    my $name = shift;
    exists $name{$name} and return $name{$name};
    grep { $_ eq $name } @name and return $name;
    return "invalid";
    } # name

[download]

FWIW, the above code is fine with me :)


Enjoy, Have FUN! H.Merijn
  • Comment on Re: Unifying namespaces of @name and $name to simplify dereferencing?
  • Download Code

Replies are listed 'Best First'.
Re^2: Unifying namespaces of @name and $name to simplify dereferencing?
by LanX (Saint) on Mar 22, 2016 at 12:29 UTC
    I don't get it.

    > would make maint a LOT harder

    maint = maintenance ?

    > 

    sub name {
    my $name = shift;
    exists $name{$name} and return $name{$name};

    [download]

    well obviously you are passing a hash ref in this model because of the curlies {}

    but then

    > 

        grep { $_ eq $name } @name and return $name;

    [download]

    this would mean grepping for a circular reference in the array???

    In standard Perl would be

    > 

        grep { $_ eq $name } @$name and return $name;

    [download]

    Not sure if this really makes sense...

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

    update

    BTW: you are still free to use -> in this model to improve readability.

    NB: -> is already optional between parens... $a->{x}[0] == $a->{x}->[0]

[reply]
[d/l]
[select]
      sub name {
    my $name = shift;
    exists $name{$name} and return $name{$name};

      [download]
      well obviously you are passing a hash ref in this model because of the curlies {}

      No. The name passed in (update: in normal behavior, obviously) is a string, the $name{...} lookup is into a previously defined hash: 

      my %name;
my @name;

      [download]
      </nitpick>

      Update: it is in your model where confusion arises about the type of the passed $name.

      perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
[reply]
[d/l]
[select]
        > Update: it is in your model where confusion arises about the type of the passed $name.

        yes you are right, $name = shift should do no aliasing automatically, Perl needs universal scalars which are untyped.

        see also my other replies, discussing typed my $name[] = ... declarations to be able to pass/assign references which work without -> operator.

        update

        > No. The name passed in (update: in normal behavior, obviously) is a string, the $name{...} lookup is into a previously defined hash:

        yes and in feature "autoref" this should never compile!

        Because of the alias $name = \%name in the upper scope a redeclaration of a simple scalar $name in the sub would make $name{...} accessing an undefined variable.

        I.o.W. identifiers must be unique in any scope and you would achieve this compile time checking without needing to use Perl Critic.

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

[reply]
[d/l]
[select]

In Section Meditations