Some 2.8 collection ideas that arose out of IRC discussion about hash codes

[David MacIver]

The bickering about this in scala-debate overflowed into #scala. The
following two concrete ideas were suggested in the course of the
discussion. I think both are interesting, independently of what is
done about mutable hash codes:


1. A freeze method on mutable collections. This would cause the
collection to throw exceptions on attempts to mutate it. An example
use case (if mutable hash codes were made to work) would be to freeze
mutable hash keys before using the collection as a key in a hash
table, thus preventing your keys from accidentally being mutated. I'm
sure there are others.

One question is whether there should also be a corresponding "thaw"
method to unfreeze it. I think there should, but I don't feel that
strongly about it. On the one hand the lack of it allows for a much
stronger this will never be mutated again guarantee. On the other hand
the major use case for it I see is to be able to specify regions where
you want to enforce that it will never be mutated.

Alternative: As well as providing a freeze method you can provide a
whileFrozen method (or something like that) with the signature

def whileFrozen[T](action : =>T) : T = { ... }

which freezes the object only for the duration of the call. It's
probably worth providing this even if there is a thaw.


2. Parameterized hashing. This is actually something I've wanted for a
while. Have collections which depend on hashing take an implicit
Hasher parameter where

trait Hasher[-T]{
  def hashOf(x : T) : Int;
  def areEqual(x : T, y : T) : Boolean;
}

this is then used to define the hashing behaviour of the collection,
much like Ordering. However there would be an implicit Hasher[Any]
available, so it would always succeed, but could specialise in some
cases.

[Tony Morris-4]

David MacIver wrote:

> trait Hasher[-T]{
>   def hashOf(x : T) : Int;
>   def areEqual(x : T, y : T) : Boolean;
> }
>
> this is then used to define the hashing behaviour of the collection,
> much like Ordering. However there would be an implicit Hasher[Any]
> available, so it would always succeed, but could specialise in some
> cases.
>
>  

Unfortunately, if you supply an implicit Hasher for a more specific type
than Any, it will not be selected over the one for Any. This is because
Hasher is a contra-variant type constructor. This is from the top of my
head, since I ran into this recently.

--
Tony Morris
http://tmorris.net/

[David MacIver]

2009/5/19 Tony Morris <tonymorris@...>:

> David MacIver wrote:
>> trait Hasher[-T]{
>>   def hashOf(x : T) : Int;
>>   def areEqual(x : T, y : T) : Boolean;
>> }
>>
>> this is then used to define the hashing behaviour of the collection,
>> much like Ordering. However there would be an implicit Hasher[Any]
>> available, so it would always succeed, but could specialise in some
>> cases.
>>
>>
> Unfortunately, if you supply an implicit Hasher for a more specific type
> than Any, it will not be selected over the one for Any. This is because
> Hasher is a contra-variant type constructor. This is from the top of my
> head, since I ran into this recently.

Hm. You seem to be correct. That's annoying.

This can be worked around by making the implicit Hasher for Any actually an

implicit def hasherForAny[T] : Hasher[T] = ...

but still, irritating!