From: "Thies C.  Arntzen" <thieso@...>
Date: 2006-08-13T17:35:04+09:00
Subject: Re: PATCH to make internal Hash class retain order...


Thies C.  Arntzen schrieb:

> Hi there -
>
> beeing new to ruby (thru rails) and coming from a strong php background
>
> i really miss beeing able to retain order in a Hash. i know that this
> has been discussed in the past i also understand that i can always
> write my own OrderedHash implemenation in user-space. -but- as a) i
> love to poke around b) userspace was too slow for some of my problems
> -and- c) it's always best to to let "code speak" i decided to "scratch
> my itch" and wrote a patch (against 1.8.4) that will:
>

hi back - replying to myself...

* it cannot be implemented "as-cool" in a C-Extension cause it would
not integrate "far" enough into ruby to have a real substantial value
IMHO. (using Mauricios patch to eval would alow to implement it fully
as an extension, but it would *slow* down *any* Hash creation in to
engine - so it's not an option)
* it was not meant as a patch to ruby for people to use - i would much
rather like to have this feature a default in upcoming versions of
ruby. so, i posted it for discussion...
* sure, changing the core-classes is a delicate thing, but -heck- why
not? a) improvment most often comes with change, and b) i have have
hacked on laguages-cores (PHP) before;-)
* i would not go as far as proposing to possibility to supply an
order-function to the hash so that it's always ordered in a
user-defined way - if you have to go that far you are better off in
user-space!
* using rb-trees has to be less efficient for simple lookups (O(?)
against O(1))


regarding possible memory-usage and speed tradeoffs:
* the memory footprint increase is tiny and we should be able to ignore
that. rubys implemenation is way more memory efficient that eg PHPs and
noone has complaint there yet.
* the same goes for speed. the lookup-speed is untoched, update is
untouched, insert is O(1) slower (a few more pointers), deletion is a
tad slower (but that could be fixed). sidenote: i even think we could
squueze a tiny bit more out of our current hash-table implementation.
i don't believe that you will be able to find any benchmark to prove
this to slow down or bloat ruby in any way...

re, tc