I’m not an expert in Go, so this comment may be way off the mark. But from my understanding, and experience of (trying to write) idiomatic Go, this type indirection is a bit atypical, isn’t it? It looks like more of something someone coming from Java would do?
On the one hand, I know that a bit of abstraction and generalization here and there is needed in anything non-trivial, but on the other, maybe I’m just stuck on a beginner level of go and htis seems incorrect to me?
If you talk about wrapping a transaction/connection: I don’t future proof by adding indirection before I see the need. But if you’re working with SQL a lot, I feel it’s handy to have utility wrappers and/or using sqlx to avoid all the boilerplate that follows from using the low-level SQL connection Go provides with the standard library.
Take a look at David Crawshaw’s sqlitex package, and in particular the Save function, which provides transaction semantics without playing games with interfaces.
Thanks. I probably didn’t do enough stuff in Go to read your examples properly, but on just a fresh read, without a lot of context, it looked like doing things like this is creating abstractions without any real benefit. It’s just that my mind thought “hey why’s he taking this directness away from me, I wanna see exactly what’s going on”.
I should probably go make a package that does this, so that I can understand better what you mean.
I’m on my phone and didn’t read it very deeply, so maybe I missed it, but what’s the advantage of using generics here vs a plain interface? ISTM that you could just have ReadTX, WriteTX, etc and have functions use or require those without using generics. Is the problem that you need something to take a ReadTX and return a ReadTX again?
It helps a lot when you want to pass the access rights from one type to another. My example was from a database connection to a database transaction. If you were to do that with interfaces you’d have to implement ReadTX, WriteTX, ReadConn and WriteConn. But if you don’t need to transfer the access rights across types then it’s not really any point in using generics over interfaces here.
I’m not an expert in Go, so this comment may be way off the mark. But from my understanding, and experience of (trying to write) idiomatic Go, this type indirection is a bit atypical, isn’t it? It looks like more of something someone coming from Java would do?
On the one hand, I know that a bit of abstraction and generalization here and there is needed in anything non-trivial, but on the other, maybe I’m just stuck on a beginner level of go and htis seems incorrect to me?
If you talk about wrapping a transaction/connection: I don’t future proof by adding indirection before I see the need. But if you’re working with SQL a lot, I feel it’s handy to have utility wrappers and/or using sqlx to avoid all the boilerplate that follows from using the low-level SQL connection Go provides with the standard library.
Take a look at David Crawshaw’s sqlitex package, and in particular the Save function, which provides transaction semantics without playing games with interfaces.
Thanks. I probably didn’t do enough stuff in Go to read your examples properly, but on just a fresh read, without a lot of context, it looked like doing things like this is creating abstractions without any real benefit. It’s just that my mind thought “hey why’s he taking this directness away from me, I wanna see exactly what’s going on”.
I should probably go make a package that does this, so that I can understand better what you mean.
I’m on my phone and didn’t read it very deeply, so maybe I missed it, but what’s the advantage of using generics here vs a plain interface? ISTM that you could just have ReadTX, WriteTX, etc and have functions use or require those without using generics. Is the problem that you need something to take a ReadTX and return a ReadTX again?
It helps a lot when you want to pass the access rights from one type to another. My example was from a database connection to a database transaction. If you were to do that with interfaces you’d have to implement ReadTX, WriteTX, ReadConn and WriteConn. But if you don’t need to transfer the access rights across types then it’s not really any point in using generics over interfaces here.
That makes sense, thanks.