in reply to Hashes do preserve insertion order after all

Allegedly the solution to a common headache I had recently: save control points to a curve path where order of insertion is important - shape depends on it. But also delete a control point in the middle of the path (by key): meaning retain insertion order and at the same time search/insert/delete O(1) by key ... hmmm

kikuchiyo please prepare a test case to prove your hack's worth (especially when memory is not large - as others here said already).

Here is a thought:

#!/usr/bin/perl

use strict;
use warnings;
use feature qw/say/;

my %hoh = (
    foo => { value => 'second', time => time},
    bar => { value => 'first', time => time},
    baz => { value => 'third', time => time},
);

for my $elem (sort {$a->{time} <=> $b->{time}} values %hoh) {
    say "value => " . $elem->{value};
}

[download]

which does not work because time() granularity is too thick/un-fine. Using DateTime::HiRes is not a guarantee either.

Should one be using instruction-based counting?

Perhaps Perl has a monotonically increasing counter, sort of like an incrementing-only program counter/instruction pointer? Alas, even than can not guarantee one instruction to insert only one hash element (can it?).

A very interesting problem which has solutions but not EFFICIENT solutions. This is one of the most ingenious I have seen.

bw, bliako

(edit: aesthetical edits a minute after posting)

Replies are listed 'Best First'.
Re^2: Hashes do preserve insertion order after all
by bliako (Abbot) on Aug 01, 2019 at 00:37 UTC

    BTW, of course this works...:

    #!/usr/bin/perl

use strict;
use warnings;
use feature qw/say/;

my $HC = 0;
my %hoh = (
    foo => { value => 'second', time => $HC++},
    bar => { value => 'first', time => $HC++},
    baz => { value => 'third', time => $HC++},
);

for my $elem (sort {$a->{time} <=> $b->{time}} values %hoh) {
    say "value => " . $elem->{value};
}

    [download]

    bw, bliako

[reply]
[d/l]
Re^2: Hashes do preserve insertion order after all
by kikuchiyo (Hermit) on Aug 01, 2019 at 16:10 UTC

    All the criticism against this hack brought up in the other replies is valid.

    I see one context where it might still have a viable use case: in very short, one shot, one liner scripts that build one data structure, transform or filter it some way then print the result. This is the context where I've discovered it by the way.

    Example: I had a complex, multilevel JSON, and I wanted a flat list of some of the values from a sub-hash. The json_xs command line script from the JSON::XS module has a mode to execute arbitrary code before printing the result, so I used the following one liner: 

    json_xs -t string -e 'my $x; for (sort values %{ $_->{database}->{data
+bases} }) {$x .= $_->{dbname}. $/;} $_=$x' < conf/test.json

    [download]

    In this (and only this) context this hack can be used quite reliably, and it has the advantage that it is concise and does not require any external modules (and presumably it is fast, because all it uses is the built-in reference stringification and sort's default lexical sorting).

[reply]
[d/l]

In Section Meditations