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

Re: undoing of auto-deref removal

Thread Previous | Thread Next
From:
L A Walsh
Date:
March 2, 2021 22:52
Subject:
Re: undoing of auto-deref removal
Message ID:
603EC1A2.7040802@tlinx.org
On 2021/03/02 12:24, Ricardo Signes wrote:
> On Tue, Mar 2, 2021, at 2:30 PM, L A Walsh wrote:
>>  As I've stated before, the only reason detractors have given for
>> allowing this is that they/you want the deref to work in the
>> case that _perl_ _doesn't_ _support_.  This is a limitation of perl, not
>> of auto-deref.  Perl cannot dereference something that is not already
>> defined as a type in the language.
>
> In general, in Perl, if something expects to be handed a reference to 
> an array, one can hand in a blessed object that provides 
> array-dereference behavior.  autoderef broke that.
---
    Looking at perlref, Perl doesn't have any functions where it expects
to be handed an array ref.  This is a place where it expects to be handed
an ARRAY.  Autoderef also allows it to be handed a reference in the same
places it accepts a real ARRAY.  A reference to another data type can't
use those functions unless it provides a METHOD to convert from the other
data type to an ARRAY. 
>
> Your argument sounds, to me, like "Yes, but it said it was going to 
> break that, so it's fine."
>
> On the other hand, it makes autoderef less appealing, because "use a 
> virtual array reference" becomes less safe.
----
    Perl never has supported a virtual array ref as identical to an array.
If someone uses it that way, it's trying to apply perl's array semantics
on non-array objects.  If those objects don't define the same operations,
that is there choice.  It doesn't break any code, because no code using
a non-ARRAY object reference could be used in those locations.

    It can only break new, unwritten code.  What you are claiming is
that perl can never be expanded in ways it was never used, because the
new ways don't support all the user-types supported by perl for builtin
objects.

    They *can*, if they provide a method.  But that's future facing -- not
past facing.  I wrote an ARRAY based class that provided the methods
for references to the class that worked with perl's builtins.  It's
quite possible for others to do the same with their classes if they want
those classes to act like ARRAYS's.
>
> At any rate, this debate happened years ago.  I considered the matter 
> settled then, and I still do now, and I don't really plan to entertain 
> further discussion on this feature.  The ship has sailed, and I'm glad 
> to see it vanished over the horizon.
---
    That's an argument listed under "logical fallacies".  "It's this way
now, so it will always be this way, thus we we have decided so help me, me."

    A pronouncement of a past judgment that is no longer true simply
means new information makes the old judgment false.  You aren't the Pope
who claims that because the church believed to be the earth flat
believes it still to be true?  New information comes along and still
upsets reality today. 

     When I was a child, it was taught that the shape of
a wing was what gave airplanes their life.  Now that is known to be false.
Indeed *most* of the thrust against gravity comes from the wing angling
down and providing a direct downward force to negate gravity.  But until
the 80's or 90's, people still believed the "truth" that had been so since
the earliest days of flight.

    You have knew knowledge -- that pseudo-array classes can provide their
own methods if they wish to retain compatibility with perl-refs that
work with ARRAY methods.  This isn't a change that causes old code to
break.  It is a change that only applies to future code that wishes to
have user-refs be compatible with perl's builtin ARRAY and HASH datatypes.

    Standing against anything that allows perl to evolve that doesn't break
old code is making perl a dead language.  The only languages that don't
evolve are dead languages -- ask speakers of Latin...except there are no
native speakers of Latin.  They are all gone.  Thus Latin is considered
by linguists to be a dead language.

    If you insist that perl not evolve -- you are consigning it to death
*by definition* ∴ -QED



Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About