3 ms·

Pardon my ignorance, but is there any functional change by it being a method vs a func? All I can think of is not having to type in the package name to call it

Pardon my ignorance, but is there any functional change by it being a method vs a func? All I can think of is not having to type in the package name to call it and possibly the ability to memoize parts within the struct itself but not sure if you'd even want that in a general solution. If the argument is one of those or aesthetic then awesome, but I'm wondering if I'm missing some difference in how Go handles them.

lobster_johnson 9y ago
Mostly aesthetics and ergonomics. Proto messages have an interface [1], but equality is strangely not part of it. Having it be a method would make it discoverable — most editors/IDEs would have Equal() show up as an "intellisense" autocompletion if you typed "msg." or similar. Having it be a package-level function means you have to read the documentation to find it. The fact that they single out reflect.DeepEquals() being used instead implies perhaps that there are people who didn't read the documentation. You could also argue that if Equal itself were an interface, it could be extended to other code beyond Protobuf. Many languages do this. Such an interface could also conceivably be leveraged by the language to support arbitrary objects as map keys and hashing in general. Rust does this [2], but requiring that a map key implement the traits Eq (which provides equality semantics throughout the language) and Hash. Traits are similar to Go interfaces. (As an additional point of elegance, Rust can generate the implementation for you, via an annotation, so for many types you can simply write #[derive(Eq, Hash)] and now your type has "==" and hash() with no additional effort.) I'm sure Go's designers wouldn't want to go down that rabbit hole, though. The only built-in interface I know about is "error", but the language itself doesn't know about it, and I don't think there are any interfaces that are leveraged by the language. [1] https://godoc.org/github.com/golang/protobuf/proto#Message https://godoc.org/github.com/golang/protobuf/proto#Message [2] https://doc.rust-lang.org/std/collections/struct.HashMap.html https://doc.rust-lang.org/std/collections/struct.HashMap.htm...

lobster_johnson 9y ago

Mostly aesthetics and ergonomics. Proto messages have an interface [1], but equality is strangely not part of it. Having it be a method would make it discoverable — most editors/IDEs would have Equal() show up as an "intellisense" autocompletion if you typed "msg." or similar. Having it be a package-level function means you have to read the documentation to find it. The fact that they single out reflect.DeepEquals() being used instead implies perhaps that there are people who didn't read the documentation. You could also argue that if Equal itself were an interface, it could be extended to other code beyond Protobuf. Many languages do this. Such an interface could also conceivably be leveraged by the language to support arbitrary objects as map keys and hashing in general. Rust does this [2], but requiring that a map key implement the traits Eq (which provides equality semantics throughout the language) and Hash. Traits are similar to Go interfaces. (As an additional point of elegance, Rust can generate the implementation for you, via an annotation, so for many types you can simply write #[derive(Eq, Hash)] and now your type has "==" and hash() with no additional effort.) I'm sure Go's designers wouldn't want to go down that rabbit hole, though. The only built-in interface I know about is "error", but the language itself doesn't know about it, and I don't think there are any interfaces that are leveraged by the language. [1] https://godoc.org/github.com/golang/protobuf/proto#Message https://godoc.org/github.com/golang/protobuf/proto#Message [2] https://doc.rust-lang.org/std/collections/struct.HashMap.html https://doc.rust-lang.org/std/collections/struct.HashMap.htm...