On Thu, 30 Jun 2016 11:57:38 -0700 (PDT)
Chad <send2b...@gmail.com> wrote:
> In fact I'd rather deal with the general issue by relaxing some
> rules, if it's something that is deemed worthy of being dealt with.
I think this part of the discussion can be safely closed: since no one
is able to specify the semantics for comparing arbitrary slice and map
values which would be overwhelmingly better (more logical etc) that the
others, the situation is unlikely to change IMO.
> Basically if you have a map[interface{}]interface{} because you have
> a mixed bag of value that you fill at runtime, you cannot actually
> use any type you want as the key.
> Semantically, there is an additional constraint that I don't believe
> should exist.
Your proposition merely moves the semantical constraint to another
place: as Ian pointed out, if we define equality for slices to be
something resembling pointer equality suddenly []byte{1, 2} is not equal
to []byte{1, 2}.
The approach I have proposed (a custom "keying" function) is actually
what "every other language" does, just more explicit. Say, .NET's
collections rely on their members implementing various interfaces such
as IHashCodeProvider. My "keying" function merely provides a mapping
from values which cannot be used as keys directly to some other values
which can -- using your own rules. Since your rules would be codified
explicitly, there would be no cognitive burden for the next programmer
reading your code.
> And it's on any type that has one or more fields of type slice/map/
> or func.
>
> The alternative is to implement one's own associative array
> datastructure with one's own hashing algorithm etc but that's still
> going to be clunky since it will be implementation dependent and will
> rely on the use of unsafe.
I propose putting such "hashing algorithm" outside of the datastructure.
Basically what I propose is replacing
collection(K → V)
with
collection(K' → V)
where K' is derived from K using your own function: K' = fn(K).
The collection stays unmodified, you just transform its keys.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
