I just ran into this... ...makes me like go a little less.
On Tuesday, August 7, 2018 at 6:34:03 AM UTC-7 mi...@daglabs.com wrote: > Sorry for bumping a very old thread, but I absolutely disagree with the > people stating that this problem is contrived, and I got here from a Google > search, so this might be relevant for some people. > > A very real use-case for reference-comparing maps is when testing .Clone() > methods. You want to make sure that the clone is an actual clone, and that > all the properties of the cloned object are also a clone, etc. In these > cases you want to reference-compare everything. > > That said, reflect.ValueOf(xxx).Pointer is more than sufficient for this > use-case. > > > On Monday, July 15, 2013 at 3:50:01 AM UTC+3, Yi DENG wrote: >> >> There're always something that is not comparable. You can consider map as >> one of this. If you have to check, use the pointer form. >> >> David >> >> On Saturday, July 13, 2013 7:35:55 PM UTC+8, Jsor wrote: >>> >>> I ask for maps because for slices this seems potentially problematic: >>> what does "same reference" entail for a slice? Overlapping underlying >>> arrays? Same starting pointer regardless of whether their len matches? Same >>> start, end, len, and cap? And so on. Though I guess "reference-equality" >>> would be pretty well defined for channels. >>> >>> However, for maps determining "sameness" at a reference level seems like >>> a much more well defined question, and a much simpler one to answer. Yet I >>> can't figure out a good way to do it. Perhaps with >>> reflect.Value.UnsafePointer (would that even work)? Either way, that seems >>> like overcomplicating things. The "easiest" way to do it seems to be >>> something like this, dreamt up on the go-nuts IRC when I asked this: >>> http://play.golang.org/p/6Ffxfx7zBb >>> >>> But I think we can all agree that that's a rather silly and limited >>> solution (and to be fair wasn't suggested in earnest). >>> >>> I can see why == isn't defined on maps, too many people would likely >>> mistake it for a deep equality test (if that was indeed the reason), but it >>> seems like there should be some semi-trivial way to see if two map >>> variables refer to the same map. Perhaps a need just wasn't seen for such >>> an operation? Maybe it's really a more difficult/expensive test than I >>> assumed? >>> >> -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/a1f4e265-4523-41be-a67a-f43610fd430a%40googlegroups.com.
