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
keys(@array) gives too many indices #11328
Comments
From @sciuriusCreated by @sciurius my @a = qw( zero one two three ); returns: number of elements = 8 For the function keys(@array) to be anything more useful than just an The same applies to values(@array), which returns a series of Perl Info
|
From @xdgOn Tue, May 10, 2011 at 7:46 AM, Johan Vromans
Dear Johan, The concept of "exists" (and "delete") on arrays has been deprecated With all due respect, I recommend closing this ticket as already Regards, |
The RT System itself - Status changed from 'new' to 'open' |
From tchrist@perl.comJohan Vromans (via RT) <perlbug-followup@perl.org> wrote
I remember having gone over this some months ago. I don't have I note that the blead perlfunc contains delete() may also be used on arrays and array slices, but its B<Be aware> that calling delete on array values is deprecated --tom |
From @sciurius[Quoting David Golden via RT, on May 10 2011, 04:59, in "Re: [perl #90240] ke"]
Could it be that the corresponding deprecation warning is missing? % blead -wlE 'my @a = qw(1 2); say exists $a[7]' -- Johan |
From @sciurius[Quoting tchrist1 via RT, on May 10 2011, 05:02, in "Re: [perl #90240] ke"]
Noe of this covers the case that I mentioned: my @a = qw( zero one two three ); No 'delete'. No 'exists'. Just an assignment and 'keys'. Two conclusions: - Assigning a value to an array element that does not currently exist - keys(@a) is just an alternative and often more elegant way to write -- Johan |
From @xdgOn Tue, May 10, 2011 at 10:31 AM, Johan Vromans <jvromans@squirrel.nl> wrote:
The underlying interpreter code for keys, values and each is the same. while ( my ($i,$v) = each @array ) { ... } The code to make that work gives us keys/values on arrays "for free". FWIW, I believe that each on arrays returns elements in order, though -- David |
From tchrist@perl.comDavid Golden <xdaveg@gmail.com> wrote
Arguably, one might be able to read that in what the second sentence =item each HASH =item each ARRAY =item each EXPR When called in list context, returns a 2-element list consisting of the key Hash entries are returned in an apparently random order. The actual random And yes, it should be more explicit. --tom |
@ikegami - Status changed from 'open' to 'rejected' |
From @ikegamiOn Tue, May 10, 2011 at 10:31 AM, Johan Vromans <jvromans@squirrel.nl>wrote:
It goes to show that the behaviour you expect/desire is slated for removal number of elements = 8 keys = 0 1 2 3 4 5 6 7 C<keys> returns the index of every element of a hash, so C<keys> should - Eric |
From andrew@cleverdomain.orgOn Tuesday, May 10, 2011 11:41:05 AM Eric Brine wrote:
C<keys> returns the indices of elements in a hash that have been assigned Implementing keys/values/each on arrays has really just been a colossally If, however, keys/values/each on arrays respected "exists", not only would |
From @ap* David Golden <xdaveg@gmail.com> [2011-05-10 14:00]:
I agree. * Tom Christiansen <tchrist@perl.com> [2011-05-10 14:05]:
Here you are: * Johan Vromans <perlbug-followup@perl.org> [2011-05-10 13:50]:
* Andrew Rodland <andrew@cleverdomain.org> [2011-05-11 04:20]:
Please read the aforelinked threads. This has already been argued (That reasoning should maybe be added to the docs. This issue is Regards, |
From @ikegamiOn Tue, May 10, 2011 at 9:57 PM, Andrew Rodland <andrew@cleverdomain.org>wrote:
Not true.
Assignment doesn't matter, only existence. Since C<<my @a; $a[7]="seven";>> |
From @sciurius[Quoting A. Pagaltzis via RT, on May 10 2011, 21:24, in "Re: [perl #90240] ke"]
Thanks.
I recommend leaving this ticket open at least until the deprecation Currently, there's only a line of text in perldelta and perlfun -- Johan |
From vadim.konovalov@alcatel-lucent.com
Maybe list deprecations in a separate file, so to made looking for them more easily? Vadim. |
From @sciurius"Konovalov, Vadim (Vadim)** CTR **" <vadim.konovalov@alcatel-lucent.com>
Do you really think programmers will actively start looking for I don't. -- Johan |
From vadim.konovalov@alcatel-lucent.com
I do think that if they will be collected together - I will browse these even more But my approach is not universal of course :) I even think deprecations deserve command line options: perl -V:deprecations Vadim. |
@cpansprout - Status changed from 'rejected' to 'open' |
From @obraOn Wed 11.May'11 at 9:00:19 +0200, Johan Vromans wrote:
My policy: If we fail to implement a deprecation warning for something -Jesse |
From @sciuriusJesse Vincent <jesse@fsck.com> writes:
Thanks Jesse, for this clear statement. To get back to the originating bug report, we now can draw the -- Johan |
From @ikegamiOn Wed, May 11, 2011 at 5:39 PM, Johan Vromans <jvromans@squirrel.nl> wrote:
The bug report was about keys() not returning the right thing. Having delete/exists return a deprecation warning is a completely different |
From @xdgOn Wed, May 11, 2011 at 5:39 PM, Johan Vromans <jvromans@squirrel.nl> wrote:
I think that's an incorrect read. A deprecation *decision* may be *implemented* improperly (without -- David |
From @cpansproutOn Tue May 10 21:24:21 2011, aristotle wrote:
http://www.nntp.perl.org/group/perl.perl5.porters/;msgid=22846.1262929665@chthon
There are some things those threads did not bring up. This was never mentioned: Nobody brought up array-based objects. I know I’m not the only one using Here is my main objection to the deprecation (which I would have raised If Perl wants to follow a C-style array model, fine. If Perl wants to It doesn’t really matter whether we like a particular model or not. If There are plenty of old features that I don’t like, but I’m not going to Here is another thing those threads did not bring up: If you never use |
From @sciurius[Quoting Father Chrysostomos via RT, on May 15 2011, 13:00, in "[perl #90240] keys(@"]
As stated earlier, I consider: @a = ( 1, 2, 3 ); equivalent to: @a = ( 1, 2, 3, 4, 5 ); In either case, exists($a[3]) returns false. This has been so for a long time (5.6 at least). Now we have added a new feature, each on arrays. Just like hashes it It's the new feature that fails, not the old one. -- Johan |
From @ikegamiOn Wed, May 11, 2011 at 7:20 PM, Eric Brine <ikegami@adaelis.com> wrote:
Not forgotten. The patch was written that night. Just handling a small issue |
From @doyEric, was this patch ever written? -doy |
From @ikegamiOn Tue Jul 03 17:17:05 2012, doy wrote:
Both the ticket and the patches were created. It is #105278 |
From @sciuriusOn Tue Jul 03 23:02:49 2012, ikegami@adaelis.com wrote:
Regardless of whether delete/exists on arrays will be actually |
From @ikegamiOn Wed Jul 04 04:50:19 2012, jv wrote:
Feel free to create a function that does what you want. keys should |
From @sciurius[Quoting Eric Brine via RT, on July 4 2012, 13:38, in "[perl #90240] keys(@"]
keys() should return the keys, we agree fully. Except that I consider -- Johan |
From zefram@fysh.orgkeys(@array) has a defined meaning that is consistent with the -zefram |
@iabyn - Status changed from 'open' to 'rejected' |
From @ikegamiOn Tue, Dec 12, 2017 at 1:56 AM, Zefram <zefram@fysh.org> wrote:
Don't even need XS. sub initialized_array_indexes(\@) { |
Migrated from rt.perl.org#90240 (status was 'rejected')
Searchable as RT90240$
The text was updated successfully, but these errors were encountered: