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

Re: undoing of auto-deref removal

Thread Previous | Thread Next
L A Walsh
March 3, 2021 10:00
Re: undoing of auto-deref removal
Message ID:
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.
    "In general"?  Please state where in the documentation for perl that 
is a documented feature.  There's no guarantee that such is a feature
in perl.  More to the point,
>   autoderef broke that.
> Your argument sounds, to me, like "Yes, but it said it was going to 
> break that, so it's fine."
    There is nothing to break.  Your statement is complete fabrication based
on what some people may have been assuming but goes against object oriented
design.  You are violating basic rules regarding OO languages.

    In the same way you claim a random blessed object provides
array dereference behavior, the same random object could be claimed to have
hash dereference behavior.  You are claiming an object can claim to be
both '0' and '1' at the same time which is clearly not a feature of a
deterministic computer language.

    When someone made that statement before, I asked, "How does Perl know
an object provides array-dereference behavior.  How can perl know if it
provides array-dereference behavior or hash-dereference behavior.  Such
a statement is meaningless since there is nothing in the language to
specify such a behavior.

    You are personally guaranteeing perl will honor something that has
no mechanism in the language to be specified.  The only way something can
provide such behavior is to provide all the methods that apply to an
Array and duplicate the behavior of perl's arrays.  If they did that,
there would be no issue with perl autodereferencing such objects, as
those methods would have been duplicated in those objects.

    What you are claiming is because some group of your buddies want
their assumptions to be true, you are willing to neuter perl because they
don't want to provide methods for their classes to actually duplicate
array behavior.

    If you continue on this path you are only proving that perl is a
personal playground of those allowed to contribute to it.  Since perl-5.18,
perl has gone from being in the top 10 languages, past the point of
being dead last and most hated to work or develop in, to falling off
the charts.  Latest charts on languages being used or liked by developers
no longer included perl.

    The current development group has abandoned most users to the point
that I've wondered  if some in leadership positions really have the
goal of killing off perl or if it just part of the larger problem
working to reduce pc ownership and computer knowledge. 

to kill perl  Perl servers are being
shut down because they have too few users and perl is being retired
because it doesn't listen to its user base and only listens to an
increasing shrinking developer base that is losing the resources to
maintain the codebase, let alone have it grown. 

    At least two years ago, I was told that there was no one on the
perl development team that knew how the language parser worked and
no one wanted to make changes in it for fear of breaking it.  I wasn't
sure whether it was true or not, but

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About