Re: Why Does Hash Apparently Reorder Its Internal Representa

<thoran / thoran.com> wrote in message
news:2d4684b07b9f965e5078fdb46754fac3@shiny…

h[0]

There’s no great call for the immediately above I would think, but if
I
implemented one then I would implement the other also, simply for the
purposes of symmetry. I’m not even sure there is any need for
either,
such that I may be trying to achieve the unnecessary?..

" How would this even work?
For instance:

hash = { 0 => ‘a’, 1 => ‘b’, ‘c’ => ‘d’ }

for me, this prints ‘a’, ‘d’, ‘b’, in that order…

hash.each { |k,e| puts e }

puts hash[1] # what will this print?

 There's no way to tell whether the last line of this code is

trying to
access the second element of the hash or the one that maps to the
Fixnum
1…"

I was aware of the ambiguity of this and that it might more reasonably
mean to access the whole pair, rather than the value.

Perhaps it WOULD be better if were to be the other way?:

h = {:a => ‘a’, :b => ‘b’}
=> {:a => ‘a’, :b => ‘b’}

h[0]
=> {:a => ‘a’}

h[[0]]
=> ‘a’

In that way you’re not required to know the key. The reference is
positional and not a reference to an index, by virtue of the double
brackets.

The suggested preferred nomenclature of [:a => ‘a’, :b => ‘b’] is
inconsistent with the literal instantiation of an empty array a = [].
Is it an associative array or is it an array? Or is it immaterial
until key-value pairs start to appear?

As before, I’m thinking out aloud. You know, pondering.

[email protected] wrote:

<thoran / thoran.com> wrote in message

[snippage]

As before, I’m thinking out aloud. You know, pondering.

This is very interesting, but in the long run I don’t see it
as being the “right” way. Not if the new class is to be
hash-like (and especially not if we’re talking about changing
Hash’s behavior, which I think most people are against anyway).

Hal