OK... :) question about hash and array literals

[Yukihiro Matsumoto]

Hi,

In message "Re: OK... question about hash and array literals"

|Personally, I'd like it to remember the order you added things in, use
|that ordering when iterating through the hash, and _optionally_ use it
|for compares.

Hmm, I thought hash order would be ignored always for compares.
Optional use of order is an interesting idea, although I want better
looking API than

| {1=>2, 3=>4}.ordered != {3=>4, 1=>2}.ordered

matz.

 

[Markus]

|Personally, I'd like it to remember the order you added things in, use
|that ordering when iterating through the hash, and _optionally_ use it
|for compares.

Matz wrote:

Hmm, I thought hash order would be ignored always for compares.

I would think it would have to, if you don't want to break the semantics
of Hash.

Matz wrote:

Optional use of order is an interesting idea, although I want better
looking API than

| {1=>2, 3=>4}.ordered != {3=>4, 1=>2}.ordered

If you make inspect (for example) respect the insertion order then you
have

{1=>2, 3=>4}.inspect != {3=>4, 1=>2}.inspect

which is at least a little less obtrusive.

It may, however, be better to have an additional class (OrderedHash, for
want of a much needed better name), in which order was respected for
both comparison and iteration.

My main concern is that just making regular hashes respect insertion
order for iteration but not comparison isn't exactly "least surprise";
so far as I know, the iteration order of hashes presently is arbitrary
but not random. In other words, for any two collections (arrays,
hashes, whatever) it is presently true that:

a == b

implies

a.collect { |x| x } == b.collect { |x| x }

but this would no longer be true.

Of course, this line of argument would be weakened if the implication
isn't true at present for hashes.


My preferred answer is to make => an operator that takes two object and
returns a hash in any context (assuming of course that the precedence
issues this raises could by resolved). That would let people define
their own extension to hash that worked however they wanted.


Or (even better in my book) make anything that matches

/[:+-=<>|*&^%?~!._]{2,6}/

or some such available as an operator (and thus, the vast majority of
them would be up for grabs for tasks such as this). Precedence &
associativity could be assigned by some convention (all equal, longer
things lower, or...?) or (though I'm not sure how it could be
implemented) user defined.

It would require a trick sort of like what is used for tOP_ASGN to keep
the parser from exploding (over 8000000 new operators? Yikes!) but I
think it might work.

To Hal: would a notation like

ordered_hash(1-->2,3-->4,...)

or

1-->2 | 3-->4 | ....

suit you (the latter assuming the precedence could be controlled or the
conventions were fortuitous)?

-- MarkusQ

 

[Ara.T.Howard]

Hi,

In message "Re: OK... question about hash and array literals"

|Personally, I'd like it to remember the order you added things in, use
|that ordering when iterating through the hash, and _optionally_ use it
|for compares.

Hmm, I thought hash order would be ignored always for compares.
Optional use of order is an interesting idea, although I want better
looking API than

| {1=>2, 3=>4}.ordered != {3=>4, 1=>2}.ordered

matz.

this is a GREAT idea! i've always thought that there is no reason hashes
could not simply remember the order of inserts and use it. as far as
comparisons i would agree they should not be ordered in general, perhaps

hash.identical other

or something that did depend on order. one of the coolest things about
ordered hashes would be their use with yaml! i use yaml configs and the lack
of hash ordering is a constant pain in my side. how difficult do you think it
would be to add order memory for hash insert operations and to use it for
each/map, etc.?

-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| A flower falls, even though we love it;
| and a weed grows, even though we do not love it.
| --Dogen
===============================================================================

 

[Martin DeMello]

Hmm, I thought hash order would be ignored always for compares.
Optional use of order is an interesting idea, although I want better
looking API than

| {1=>2, 3=>4}.ordered != {3=>4, 1=>2}.ordered

How about { 1=>2, 3=>4 } !~ { 3=>4, 1=>2 }
{ 1=>2, 3=>4 } =~ { 1=>2, 3=>4 }

OTOH, that syntax might more profitably be reserved for pattern
matching, which would also be a nice thing to have.

martin

 

[Hal Fulton]

How about { 1=>2, 3=>4 } !~ { 3=>4, 1=>2 }
{ 1=>2, 3=>4 } =~ { 1=>2, 3=>4 }

OTOH, that syntax might more profitably be reserved for pattern
matching, which would also be a nice thing to have.

I am not especially worried about testing equality with or without
order.

In nearly five years of Ruby, I cannot recall ever comparing two
hashes for equality at all.

But if I could have guaranteed order in hash literals and insertion
order preserved in general, I would be very happy.

More than half the code I have written would benefit from that in
some small way (including where I use YAML).


Hal

 

[Tim Sutherland]

In nearly five years of Ruby, I cannot recall ever comparing two
hashes for equality at all.

[...]

My test cases often use assert_equal on two hashes.

 

[Simon Strandgaard]

In nearly five years of Ruby, I cannot recall ever comparing two
hashes for equality at all.

[...]

My test cases often use assert_equal on two hashes.

Im also comparing two hashes.. and often find it hard to do because #default
is set to a lambda method.

 

[Ara.T.Howard]

I am not especially worried about testing equality with or without
order.

In nearly five years of Ruby, I cannot recall ever comparing two
hashes for equality at all.

database apis may use hashes as tuples so you end up comparing them. this is
also a can where

a = tuples.first
b = tuples.last

a[field] = b[field]

cmp = a == b

may, or may not, require the notion of insertion order.

-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| A flower falls, even though we love it;
| and a weed grows, even though we do not love it.
| --Dogen
===============================================================================

 

[Hal Fulton]

In nearly five years of Ruby, I cannot recall ever comparing two
hashes for equality at all.

[...]

My test cases often use assert_equal on two hashes.

That makes perfect sense, and is obvious now that you mention it.


Hal