Hi Maciej,

Could you provide a use case for that ?

1. Equality is quaranteed by the interface but there is nowhere specified what the equality is.
2. In other languages it is either part of an object or is possible to get it (although not by unified interface).
3. In current collections it is part of interface anyway. It seems to be a repetetive among the collections.
4. In bug 589801 patch (attachment 140686 [details] [review] - although it may be dead end code) I used it anyway in the AbstractMap.

Maciej,

1. equal funcs are not defined for all the collections. For instance TreeSet and TreeMap just use compare_func. Adding equal_func would require adding that argument to constructors for some implementations that do not need it.

2. The fact that GObject does not provide means to get the equal func for any type is independent of Gee. However we do provide Gee.Functions.* helper method that return has, equal and compare for basic known types.

3. The functions used by specific collection implementations are indeed made public but we cannot generalize that at the interface level. Just check out the different implementations again, please.

4. We must find another way to achieve the same thing.

(In reply to comment #3)
> Maciej,
> 
> 1. equal funcs are not defined for all the collections. For instance TreeSet
> and TreeMap just use compare_func. Adding equal_func would require adding that
> argument to constructors for some implementations that do not need it.
> 

Point taken. I'm currently spend time with Haskell where deriving equal_func from compare_func is trivial (it would be trivial with user_data but that's different discussion).

> 2. The fact that GObject does not provide means to get the equal func for any
> type is independent of Gee. However we do provide Gee.Functions.* helper method
> that return has, equal and compare for basic known types.
> 

I meant that in Java I have access to Comparator Object.

(In reply to comment #4)
> > 2. The fact that GObject does not provide means to get the equal func for any
> > type is independent of Gee. However we do provide Gee.Functions.* helper method
> > that return has, equal and compare for basic known types.
> > 
> 
> I meant that in Java I have access to Comparator Object.

SortedSet and SortedMap interfaces that we will extract from TreeSet and TreeMap are opportunities to exhibit the comparator used by these implementations. Those interfaces just describe that their a natural ordering enforced byt their implementations. And we will define a such method in those interfaces along to services provided by their inherent natural ordering:

CompareFunc get_compare_func ()

(see my proposal in 589521 about that)

But we cannot put that as part of the base interface as nothing in the API contracts enforce any order. As such the fact that some implementations use either equality, hash or comparison to maintain the storage should be considered as an implementation detail. The fact that we give some public properties for the ones that instantiate of the collections is just a convenience. IMHO, those could even be removed.