Re: Re: Consistent order of (keys %hash)?

Agreed.

To the original poster: relying on an implementation detail like this to do something useful is a bad idea. Especially when it's clearly stated (or at least implied) in the language documentation that the order shouldn't be relied on.

It might be fine for a JAPH or a 1-liner, but using this feature anywhere important is foolish; if the implementation changes, or someone ties the hash an application could screw up...

Comment on Re: Re: Consistent order of (keys %hash)?

Replies are listed 'Best First'.
(tye)Re: Consistent order of (keys %hash)? by tye (Sage) on Nov 09, 2001 at 01:57 UTC
The fact that repeated calls to `keys %hash` always returns the exact same thing right down to the order of the keys isn't an implementation detail; it is documented behavior. If you don't modify %hash, then you can be assured that the order of items returned by keys, values, and each is consistant no matter how many times you call them. A tied hash that violates this rule would be rather strange. Even DB* hashes obey this rule. It is an important rule because it allows code like: `%copy{keys %hash}= values %hash;` to work (which efficiently merges %hash into %copy). - tye (but my friends call me "Tye")	[reply] [d/l] [select]

Replies are listed 'Best First'.

(tye)Re: Consistent order of (keys %hash)?
by tye (Sage) on Nov 09, 2001 at 01:57 UTC

The fact that repeated calls to keys %hash always returns the exact same thing right down to the order of the keys isn't an implementation detail; it is documented behavior. If you don't modify %hash, then you can be assured that the order of items returned by keys, values, and each is consistant no matter how many times you call them.

A tied hash that violates this rule would be rather strange. Even DB* hashes obey this rule.

It is an important rule because it allows code like: %copy{keys %hash}= values %hash; to work (which efficiently merges %hash into %copy).

tye

[reply]
[d/l]
[select]