Front page | perl.perl5.porters |
Postings from June 2021
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 heads. 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 auto-deref.Thread Previous | Thread Next