develooper Front page | perl.perl5.porters | Postings from March 2021

Re: undoing of auto-deref removal

Thread Previous | Thread Next
March 5, 2021 00:56
Re: undoing of auto-deref removal
Message ID:
From the keyboard of Ricardo Signes [02.03.21,19:19]:

> On Tue, Mar 2, 2021, at 5:52 PM, L A Walsh wrote:
>           If you insist that perl not evolve -- you are consigning it to death
> *by definition* ∴ -QED
> You're not talking about evolution, you're talking about bringing back the dinosaurs, which
> have already sprung into existence, had their lives, and died.  I have already seen
> Jurassic Park, and I know how that ends.

Can we please abstain from blowing up a mouse to the size of an elefant?
We are talking about syntactic sugar here, not about dinosaurs - "multi
dimensional array emulation" (think $;) is a dinosaur in that scheme,
while autoderef is not.

But sugar can be poisonous. Some say it is always poisonous if not found
in an aggregate.

As a long-time perl user (my first perl was v4 patchlevel 16) these are
my few cents...

> autoderef is not coming back.

I don't object, and here is why - plus some other remarks:

1. I want to be clear in what I'm talking about. $foo is a SCALAR, %foo
    is a HASH, @foo an ARRAY. If $foo contains a reference to a HASH, I
    talk about it as %$foo, if ARRAY, then @$foo. The 'autoderef' thingy
    blurs that and "goes PHP", where any variable is prefixed with "$".

2. I have never used auto-deref, and where I (accidentally) did, it did
    not help. Trading a keystroke for clarity is a bad deal.

3. All that talk about native type vs. blessed native type aka objects
    goes right back to the (permissive) implementation of objects in perl
    where a blessed hash reference can be used as, well, a hash reference
    and as an object which calles methods. Which was arguably a bad idea,
    but that ship has sailed long ago.

4. I never used postfix-deref - $foo->@* and such - which in my eyes is
    an abomination turning the sigil system upside down. It is another
    hurdle for those having to wrap around their head at @{$h->{$a->[$i]}}

5. Making "keys", "values" and "each" work on arrays is a spectacular
    braindead decision. When has this been called for? based on what
    rationale? In my book, "keys" refers to the keys of an associative
    array, "values" to the values only, and "each" to tuples comprised
    of both of them. Nothing to do with arrays, whose entries are
    accessed via indices, and if flattened give a list.

6. All those snarky remarks about merits of perl core developer folks
    I read in the links shown in this thread are uncalled for and make
    me very sad. They are in no way perlish.

7. That said, if someone wants rope to hang themselves, give 'em.
    'autoderef' could be a feature as is 'arraybase' (wait, is that in
    place anymore?) if not too much work - and if it is, that should be
    cared of by those who want the "feature".

I know that these remarks are uncalled for, but I needed to vent a bit
and provide a view of "someone out there" with no stakes in the perl
core development. Sorry for wasting your time, and thanks for the
attention so far.

best regards - and keep up the good work,

> -- 
> rjbs

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                               /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About