From: Sven Suska <software617rf@...>
Date: 2006-08-24T23:48:22+09:00
Subject: HistoryHash --was: A use case for an ordered Hash

Pit Capitain wrote:
> In order to replace the standard Hash with a "better" Hash, there should
> be a clear agreement on its desired behaviour. I don't think this
> agreement has been achieved yet. What should be the result of the
> following code?
> 
>    hh = HistoryHash.new
>    hh[:one] = 1
>    hh[:two] = 2
>    hh[:one] = 3
>    hh.each do |k, v| p k end
> 
> Should it be
>    :one
>    :two
> or
>    :two
>    :one
> Why should it be the one or the other?

Hi Pit,

the first is the semantics of replacement,
the second the semantics of addition.

I think that replacement should be the normal semantics,
the second can then always be achieved by deleting the key
before assigning the new value.

The other way round, ie if addition were the default semantics,
we were forced to write hh[:one].replace( ), which does not
work for Fixnums.



But anyway, the recent posts induced some second thoughts in me
about having HistoryHash as the standard Hash:

Always having to keep the order can also be a drawback,
for instance:
Future core Ruby support for parallel execution could be such
that it allows different threads to add keys to one hash
and leave it undefined in which order the additions were made.

So, I am inclined to say:
Yes, OK, OK, the "good old" Hash is the cleaner solution.

Although the HistoryHash would have fitted better to my idea of
"parameter-list as Hash". But perhaps that really was too crazy.



Anyway, the performance cost of a HistoryHash would be
the cost of keeping an extra list of the entries,
this means (only) a pointer per entry.


Regards

Sven


> 
> Regards,
> Pit


-- 
Posted via http://www.ruby-forum.com/.