Front page | perl.perl5.porters |
Postings from May 2021
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
indirect
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
member
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
incompatible
with any existing program because currently you cannot use an object
reference
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
provide
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
access
of $ar->[] or $hr->{}.
The rational for removing the auto-deref feature violates the
established
feature of perl already providing random-member access of existing
Arrays and
Hashes. You can't violate current compatibility with perl in order to
prohibit
new features that take advantage of existing perl-behaviors. To do so
breaks
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