> Set#hashCode is specified as "the sum of the hash codes of the element".
Yes, I know. There's only one call to Set.hashCode() in the code base
(and that is in a test). So we won't need such a method.
If people did ever need to hash sets we'd encourage them to hash a
deterministically ordered
>Hashes
Ok
>I would imagine that there would be various functions
>static int hash(Object v0, int v1)
I was not planning to add `int` overloads. At least, I don't want to add
2^N overloads like (Object, int, int, Object).
I'll check if (Object, Object, Object) is enough.
I hope that escape
I suggest Hashes.
(Hasher in English is a noun - 'one who hashes’ - and therefore suggests that
it would be instantiated.)
I would imagine that there would be various functions
static int hash(Object v0, Object v1)
static int hash(Object v0, int v1)
static int hash(int v0, Object v1)
>The name Hasher implies that it would be an object. Could it not be just a
set of static methods?
Do you have naming suggestions?
I think Objects would be worse as it would conflict with j.u.Objects.
>Is there a library that does this for us?
I am afraid it would be easier/faster to just write
The name Hasher implies that it would be an object. Could it not be just a set
of static methods?
Is there a library that does this for us?
> On Jul 17, 2020, at 7:26 AM, Haisheng Yuan wrote:
>
> +1
> I am not sure the difference will be observable in real Calcite application,
> because
+1
I am not sure the difference will be observable in real Calcite application,
because object allocation in Java is pretty efficient. But it is always good to
avoid unnecessary object allocation and reduce GC pressure if we can achieve it
easily.
On 2020/07/17 09:36:06, Vladimir Sitnikov
Hi,
java.lang.Objects.hash is convenient, however, it does result in memory
allocation for varargs.
In practice, it can easily be visible in the benchmarks (at least for Java
1.8), so I suggest we create our own API
and use it instead of java.util.Objects#hash
We can have "up to 10 overloads"
