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. For more options, visit https://groups.google.com/d/optout.
