in reply to Re: Perl v5.13.7 is released
in thread Perl v5.13.7 is released

I don't like that change. It adds more to the syntax confusion than it takes away. If I'm pushing values into an array, I expect the argument to be some kind of array. It feels natural in Perl. All those sigil-mangling changes (and I'd like to include Perl6's sigil immutability here) stray from that (relatively simple) direction.

Automatic dereferencing syntax (meaning: s/@$/@/ or s/@{$ref}/@ref/) would be more useful. For example: 

|----------------------------+---------------------------|
| Traditional syntax         | Auto syntax               |
|----------------------------+---------------------------|
| push @$arrayref, @stuff    | push @arrayref, @stuff    |
| unshift @$arrayref, @stuff | unshift @arrayref, @stuff |
| pop @$arrayref             | pop @arrayref             |
| shift @$arrayref           | shift @arrayref           |
| splice @$arrayref, 0, 2    | splice @arrayref, 0, 2    |
| keys %$hashref             | keys @hashref             |
| keys @$arrayref            | keys @arrayref            |
| values %$hashref           | values @hashref           |
| values @$arrayref          | values @arrayref          |
| ($k,$v) = each %$hashref   | ($k,$v) = each @hashref   |
| ($k,$v) = each @$arrayref  | ($k,$v) = each @arrayref  |
|----------------------------+---------------------------|
I was following the p5p discussion about these changes, but I kept silent, so it's probably too late for this kind of rant now :)

Replies are listed 'Best First'.
Re^3: Perl v5.13.7 is released
by LanX (Saint) on Nov 22, 2010 at 15:29 UTC
    > Automatic dereferencing syntax (meaning: s/@$/@/ or s/@{$ref}/@ref/) would be more useful.

    You're well aware of the fact that @ref and $ref are different variables with disjunct name-spaces in Perl?

    IMHO this ambiguity would produce hard to track bugs.

    Cheers Rolf

[reply]
      I'm aware that this is special case for those core functions operating on arrays. So, it's not so hard to track it at all, I think.

      Actually, I don't understand why we need such syntax simplifications it they're not done through all the Perl. Changing Perl philosophy in one place, and not changing it in another is inconsistent and wrong. For example, we still don't have saner defaults for simple object-oriented programming although it is relatively simple to patch the core as demonstrated before on p5p.

[reply]
        AFAIK Perl's sources are after a long historical evolution quite complex to change.

        Changing the prototype signature of those built-in functions is OTOH comparatively easy done and without risk of compatibility breach.

        Cheers Rolf

[reply]
Re^3: Perl v5.13.7 is released
by syphilis (Archbishop) on Nov 24, 2010 at 04:41 UTC
    I don't like that change. It adds more to the syntax confusion than it takes away.

    My immediate reaction is also one of disappointment.
    Given time, I expect we'll be able to push $arref1, $arref2
    Not sure if that will make me more disappointed or less disappointed ....

    Cheers,
    Rob
[reply]
[d/l]
      Given time, I expect we'll be able to push $arref1, $arref2
      I don't think so (if you expect that would be equivalent to push $arref1, @$arref2), because it's ambiguous (do you want to push the ref $arref2 itself or the array's elements?), while the current change isn't. Only the programmer can resolve that ambiguity...
[reply]
[d/l]
[select]
        Only the programmer can resolve that ambiguity

        Hmph ... so much for perl's fabled DWIM capabilities !!!

        ;-)

        Cheers,
        Rob
[reply]
          (do you want to push the ref $arref2 itself or the array's elements?)

        Interesting point, but wrong, I think. The change that 5.13.7 introduces only affects the first argument of a push; subsequent arguments behave as before.

        Alex / talexb / Toronto

        "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

[reply]
[d/l]
[select]

In Section Perl News