Also, I kind of assume that you have little control over the types (given
that you say it's infeasible to touch all places where it's created) but
the simplest solution might, of course, be to make the zero value of Node
implement Lockable correctly:
type Node struct {
BasicNode // Note: By not using a pointer, this can not be nil.
payload int32
}
Now, `*Node` implements `Lockable` correctly (but `Node` itself doesn't, as
`BasicNode`s methods have pointer receivers).
If you can do that it might side-step a lot of your problems. But if you
can do that and if the result would still be semantically correct depends,
of course, on what the meaning behind your types is. Which I don't know.
On Thu, Mar 17, 2022 at 1:05 AM Axel Wagner <axel.wagner...@googlemail.com>
wrote:
> Let me make one more concrete suggestion:
>
> On Thu, Mar 17, 2022 at 12:18 AM Alex Besogonov <alex.besogo...@gmail.com>
> wrote:
>
>> The real example would look like this: https://go.dev/play/p/mwUfh4_RBUU
>> - you do see why it's a tad problematic?
>>
>
> Here is how you could write that, assuming `GetNode` returns a `*Node`:
> https://go.dev/play/p/7oGL2F1QgON
> It avoids having to write nested conditionals, while also not storing
> invalid Nodes in a `Lockable`.
>
> This is just to illustrate that there are sensible middle-grounds,
> avoiding storing an invalid `Lockable` in a place where you still have the
> concrete type information, while still writing reasonable convenient code.
>
> The point is just that the check for validity should happen *before*
> assigning the `Node` to a `Lockable`, not after. If you have to do it in
> `store.GetNode` (or file a bug against its owners), because that's where
> the assignment happens, then that's where it should happen. If it's
> something you do in your code, it should happen at that point.
> Find wherever you assign a `Node` to a `Lockable` and insert a check
> there. If there are many such places, you can write a helper-function to
> make it easier, e.g.
> func IsLockable(n *Node) bool { return n != nil && n.BasicNode != nil }
>
--
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/CAEkBMfF%3DYQ8K7qYWTtBYnhJy64Ftf7shuFz%3DMS6RnOhGp32Emw%40mail.gmail.com.
