in reply to Curious: are anon-hashes in random order?

Where does the random order come into play?

constant defines/explains your use case IMO.

You could make things easier by posting self-contained Perl code that doesn't rely on multiple modules that don't seem to be necessary for operation. For example the definition of a shell alias doesn't seem to contribute and neither does the P module.

Maybe you can explain what you see that happens and what you think should happen instead.

Most likely, what you're seeing is that your mem module is equivalent to a simple BEGIN block.

Replies are listed 'Best First'.
Re^2: Curious: are anon-hashes in random order?
by perl-diddler (Chaplain) on Sep 13, 2016 at 13:55 UTC
    I create my aliases and modules to simplify and shorten typing and thereby increase correctness. If they aren't contained in CPAN (like the alias), I would include them.

    It's so much more convenient to type 'tperl' when i want to test something in perl.

    If you have an equivalent source case that is as simple and short, I'd be happy to use it, but perl tends toward being expansive. But demonstrating "use constants" without using any modules (when constants is a module) seems a bit impossible. Why would you try?

    "Most likely, what you're seeing is that your mem module is equivalent to a simple BEGIN block."
    Of course, but shorter. use mem wasn't the point. Anyone who knows intermediate perl would likely know that. I just don't like putting BEGIN{} blocks that 'should' be indented, in the middle of my module headers. use mem's primary use is to enable using a package in the same file just like it would function in a separate file. The use mem(xxx) form is documented to make it official that anything you want to put in parens on the same line, is "OK" -- it won't cause a problem. I don't think other modules guarantee that. Since both involve bringing things "inline", I grouped them together in the same module.

    It would be rather lame to come up with a module just to be able to safely init things at runtime -- that sole purpose was to guarantee the passed arguments would never cause an error in future code (by assigning some semantic meaning to the arglist passed to the module), don't you agree?

    The point was that the hash isn't in random order...Ah... it's the pairs that are in random order, now that makes more sense. I.e. if you print out the clist hash, it's not in the order it was entered, but that doesn't matter as long as the pairs are kept together. Was thinking about using a qw(continue 0 next 1 redo 2 last 3), as an initializer but the randomness of hashes had me wondering why that worked -- but they'll still be kept as pairs in any randomized hash...

[reply]
[d/l]
[select]
      "Was thinking about using a qw(continue 0 next 1 redo 2 last 3), as an initializer but the randomness of hashes had me wondering why that worked -- but they'll still be kept as pairs in any randomized hash..."

      Yes, because a list is always ordered. Here's a very common idiom in parameter parsing:

      sub blah {
    my %args = @_;
    ...
}

      [download]

      It simply takes the elements in order, assigning the first as the key and the second as the value until all elements have been assigned to the hash.

      You can call the sub in numerous ways, and get the same result:

      blah(qw(continue 0 next 1 redo 2 last 3));
blah('continue', 0, 'next', 1, 'redo', 2, 'last', 3);
blah(continue => 0, next => 1, redo => 2, last => 3);

my %h = (continue => 0, next => 1, redo => 2, last => 3);
blah(%h);

      [download]
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom