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

Re: undoing breakage of perl-compatibility (removal of auto-deref)

Thread Previous | Thread Next
L A Walsh
May 22, 2021 21:43
Re: undoing breakage of perl-compatibility (removal of auto-deref)
Message ID:
On 2021/03/03 11:30, Ricardo Signes wrote:
> On Wed, Mar 3, 2021, at 5:00 AM, L A Walsh wrote:
>>> 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 this is a documented feature. 
> perldoc "overload" under "Dereferencing."
    I left this for a while because I wanted to make sure I understood
the issue(s) and I was getting too stressed/distressed by things
that didn't make sense.

    The text under "overload" doesn't guarantee what you think it does.
While it says that "if something expects to be handed a reference to an
array, one can hand a blessed object that provides
array-dereference behavior".  We'll assume that the same would hold true
for hashes as well.

        Perl currently provides an "element dereference ability" for 
arrays and hashes.  I.e. given a reference to an array or to a hash, perl
can directly access a member of that array or hash using $V->[<index>]
and $v->{<key>}, _respectively_.  You can't use [] for hash access nor
{} for array access.  _Neither_ method of referencing an array or hash 
will work for class or object references.  Perl lacks such a feature.

    Statements like 'keys' and 'values' require one of ('arrays', 'hashes').
It is an *exclusive-OR*.  They require something be one ^ the other.  That
is the requirement that "auto-deref" uses.  You cannot claim auto-deref
introduces a new incompatibility.  Neither allowing auto-deref be 
with any existing program because currently you cannot use an object 
in anyplace where 'real arrays' and 'real hashes' are used.

    There is no "incompatibility".

    If people want an object to work in such situations, they need to 
a mechanism that perl can fallback on to resolve the object into an array or
hash (like @ISA(HASH)/@ISA(ARRAY) providing for a default-auto-deref type
for classes that wish to implent such a feature).  If classes don't wish
to access the new functionality provided by auto-deref, they don't have to
do anything -- no more than they would be able to access random-member 
of $ar->[] or $hr->{}.

    The rational for removing the auto-deref feature violates the 
feature of perl already providing random-member access of existing 
Arrays and
Hashes.  You can't violate current compatibility with perl in order to 
new features that take advantage of existing perl-behaviors.  To do so 
existing compatibility by forbidding new features that are compatible with
perl existing syntax.
>> [Such statement are] meaningless since there is nothing in the language to
>> specify such a behavior.
> "overload" is a well defined mechanism.  This has been present since at least 5.005.
    That was documented to have bugs before 5.14 and 5.16 -- when auto-deref
was already implemented.  Regardless -- overload has disclaimers in
BUGS and PITFALLS -- where it acknowledges incompatibility problems with
the existing perl.  Thus it cannot be used as a canonical reference to
what is allowed or provided in perl.


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