New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EXISTS and SCALAR return values are treated differently #12383
Comments
From bmb@Mail.Libs.UGA.EDUCreated by bmb@mail.libs.uga.eduOnce upon a time, exists() returned the true value that EXISTS() When that changed, I changed my program, so I'm not reporting that This doesn't break any of my code. I'm reporting for two reasons: 1. I think it would be good for perl to be consistent, i.e., if 2. The docs might mention that this conversion to 1/"" is happening, use strict; sub show { print ">".join(",",@_)."<\n" } tie my %h1, 'P1'; show h1 => exists $h1{'hey'}, scalar %h1; package P1; sub TIEHASH { bless {}, shift } package P2; sub TIEHASH { bless {},shift } package P3; sub TIEHASH { bless {},shift } Output:
Meaning: P1: exists() returns perl's true values, scalar context, mine Perl Info
|
From @cpansproutOn Fri Sep 07 09:24:56 2012, baxter.brad wrote:
Currently scalar(%untied_hash) returns 0 (not "") for an empty hash and However, there is talk about making it return a simple boolean, for If we don’t make that change, then what you propose would not be -- Father Chrysostomos |
The RT System itself - Status changed from 'new' to 'open' |
From bmb@Mail.Libs.UGA.EDUOn 9/7/12, Father Chrysostomos via RT <perlbug-followup@perl.org> wrote:
If this is deemed small potatoes enough to be a won't fix, I won't be Regards, Brad |
From bmb@Mail.Libs.UGA.EDUOn 9/7/12, Father Chrysostomos via RT <perlbug-followup@perl.org> wrote:
It occurs to me to wonder then if the answer (for consistency) is to It strikes me as "unperlish" to have exist() change my explicit return -- |
From @demerphqOn 10 September 2012 15:59, Brad Baxter <bmb@mail.libs.uga.edu> wrote:
I have code to add a way to get detailed hash utilization stats. At that point there is no need at all for the behavior of keys in And at that point there need be no difference. Yves -- |
From @rjbs* demerphq <demerphq@gmail.com> [2012-09-10T10:15:54]
Where's it at? :) -- |
From @demerphqOn 10 September 2012 17:38, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
commit 064454668c9c3bb81c99f1b23776d9ada6305c86 add routines for introspecting hash utilization to the Internals namespace my ($keys,$buckets,$used_buckets, $max_used_bucket_chain, my ($key_info_array)= Internals::bucket_array($hashref); bucket_array() returns an AoA of keys per bucket in the order they are bucket_into() returns a detailed summary of the utilization and Work In Progress. Here is an example of usage. Im not so happy with the interface, so $ time ./perl -Ilib -MData::Dumper -le'$x="AAAAAA"; for my $i (1 .. real 0m12.096s -- |
From zefram@fysh.orgThe behaviour is not a bug, and indeed it's a general feature of the tied -zefram |
@iabyn - Status changed from 'open' to 'rejected' |
Migrated from rt.perl.org#114786 (status was 'rejected')
Searchable as RT114786$
The text was updated successfully, but these errors were encountered: