Quoting robert engels (2018-10-20 12:15:52)
> To be clear, this is only for that "performance case", where I don't
> want LinkedList to allocate internal nodes to hold the elements but the
> reasoning applies when using a simple LinkedList, and I want it to hold
> MyObj (which is not a Node, so the LinkedList needs to create Node
> instances).
Aha, we're talking about intrusive data structures. That makes sense.
I agree it's a bit awkward to have to write:
type HasNode interface {
GetNode() *Node
}
But you could do it and it solves the problem. It's been pointed out
elsewhere that this would also be solved by allowing interfaces to
specify fields:
type HasNode interface {
Node *Node
}
Ian T points out that there is an issue about this, which was rejected:
https://github.com/golang/go/issues/23796
I think most the arguments there apply to the current proposal as well.
It seems like it might have more utility in the presence of generics
though, as it would actually be possible to write the linked list once.
My inclination is still to just punt on the field thing; I don't like
that it encourages specifying implementation rather than behavior, and
it is still possible to write intrusive data structures without it.
-Ian
--
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.
