FWIW I understand that I come off as unsympathetic, insisting that you should fix the incorrect code, even though it is hard. But I am *very* sympathetic. I know perfectly well what it means to inherit a messy code base full of bugs and be overwhelmed by the amount of effort needed to fix it.
But clearly, the solution can't be to change the language on a whim. Changing the language is even harder and it affects even more people and requires us to touch even more code - by several orders of magnitude. And that's assuming we could even agree on *what* to change. That's why I'm insistent that the solution has to be to fix your code. The language as it is *can* work just fine. There are many programmers using it very effectively for very large projects. It does require working with it, not against it. And sometimes that is hard and it means having to touch a lot of code someone else wrote, to fix a problem they unknowingly introduced. It's difficult, but the alternatives are even more so. On Thu, Mar 17, 2022 at 12:31 AM Axel Wagner <axel.wagner...@googlemail.com> wrote: > > > On Thu, Mar 17, 2022 at 12:18 AM Alex Besogonov <alex.besogo...@gmail.com> > wrote: > >> No. It should be a POINTER to a struct, which would have been fine. >> Instead Go's reflection incorrectly latches on the type of the embedding >> structure. >> > > Your code says: > > var n3 Node > LockObjects(n2, n3, n1) > > You are thus storing a `Node`, which is a struct value, in a `Lockable`. > It's not a pointer. > And the `reflect` package behaves correctly. > > >> The code is NOT using anything incorrect. >> > > We apparently have to agree to disagree. To me, passing around an > interface value where every method call panics is a clear example of > incorrect code. It is like writing a Boom io.Reader and claiming that the > code is correct and the language is wrong for panicing when using it. > > The interface is obtained through a pointer to a struct, which is >> completely valid. The only problem is that this pointer is embedded inside >> a struct. >> >> If you rewrite the code to use a named field, it would work. This means >> that the language behaves differently depending on a field having a name. >> > > Well, yes. That's the point of embedding, after all. That is working as > intended. > > The real example would look like this: https://go.dev/play/p/mwUfh4_RBUU >> - you do see why it's a tad problematic? >> > > Not really, no. It doesn't seem to change the basic properties of the code. > > I don't know what the return type of `store.GetNode` is: > - If it is `Lockable`, it clearly should not return a `Node` with a nil > `*BasicNode` field, as that is an invalid implementation of `Lockable`. > - If it is `Node`, then you clearly shouldn't check `n1 == nil`, but > perhaps `n1 == nil || n1.BasicNode == nil`, before assigning it to > `Lockable` (in the call to `LockObjects`). > > Either way, some piece of code is assigning an invalid `Node` value to a > `Lockable`. That code must be fixed, to no longer do that. Neither of these > pieces of code seems particularly hard to fix. > >> -- >> 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/58d5770b-4888-4980-8f9e-c96310d57490n%40googlegroups.com >> <https://groups.google.com/d/msgid/golang-nuts/58d5770b-4888-4980-8f9e-c96310d57490n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/CAEkBMfEwVNp%2BVeAmM3bf0Ro0fYKHbo5oQvYoS9NNt8Z4k%2BVp1w%40mail.gmail.com.
