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