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

Re: undoing of auto-deref removal

Thread Previous | Thread Next
L A Walsh
June 11, 2021 03:57
Re: undoing of auto-deref removal
Message ID:
On 2021/02/28 00:18, Veesh Goldman wrote:
> I don't see how you came to this conclusion.
> Very simply, you are requesting a misfeatures. If you are writing a 
> sub, now you have to be defensive and check that the array-like thing 
> that was passed in isn't an object. You literally only gain bugs by 
> subtly disallowing Mojo::Collection objects to be passed in even 
> though they are INTENDED to be used as an array.
> Your arguments about objects being opaque is also misled. Objects ARE 
> opaque, and therefore if they tell you that they can be used as an 
> array, it shouldn't matter if its blessed or not.
This is where the breakage occurs.  How are "they" telling a user
like me _anything_.  Users don't hear the voices of objects.

I asked, how are the objects telling *perl* what they are.
I even suggested they could claim they "ISA" an ARRAY,
I did that with a HASH based class and 'keys' was able to
tell that what it was.  It works, it's simple. and it works
by telling PERL what it is.  But a class can't tell 'users'
anything because users aren't executing the programs in their

The whole reason for disallowing perl to deref its native types
was because class writers refused to come up with a way to participate
in the benefit, and in a classic sour grapes ploy claimed that
perl's native data types shouldn't be able to benefit either.

If that's the case, then all of the functions that currently
work with ARRAY's and HASHES (push/pop/keys, etc) should be
removed because they give special treatment to native data
structures.  But that wouldn't be compatible -- and that
really is the point -- perl has NEVER supported object's using
those functions.  When it was proposed that ref's to perl's
own data types be allowed in those functions, it's not _breaking_
any existing functionality -- because those functions have NEVER
worked on objects -- nor have they worked on reference to those
objects unless the coders have put '@' or '%' on the objects.
Disallowing perl to dereference its native data structures
is hamstring perl for the sake of alien data structures that
are not builtin.

If they want to participate, they should have come up with a
method to do so rather than disallowing perl an easier way
to reference its own native data structures.  Regardless,
I did come up with a way for objects that want to declare
themselves, to perl (not to users!), that they want to be
treated as arrays or hashes, to also be autoderef'ed.

The method you claim isn't there for objects is. The choice to
use it or not is on those providing the objects.  Perl can't
do their work for them.  It knows how to auto-deref it's own
data types, and that's it.  To prevent that is extreme laziness
and self-centered-ness.  It's the unwillingness to make use
of a technically correct solution because ...?  No comment.

There is no valid technical reason to disallow the undoing of

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