Re: [go-nuts] Re: smarter way to provide interface capabilities from underlining interface

2023-06-12 Thread Brian Candler
On Monday, 12 June 2023 at 07:55:24 UTC+1 Brian Candler wrote: I don't know if it's possible to use 'reflect' to build the struct type dynamically FWIW, I tried it, but could only make a program which crashes spectacularly. https://go.dev/play/p/BIFFT3FgUrz There is a comment in the

Re: [go-nuts] Re: smarter way to provide interface capabilities from underlining interface

2023-06-12 Thread Brian Candler
If runtime is a problem, then you could use a lookup table. Suppose you have (say) 10 possible interfaces in the object: then you test those ten, build a 10-bit binary number from the 'ok' values, and use this as an index into 2^10 possible constructor functions. You still need to compile

Re: [go-nuts] Re: smarter way to provide interface capabilities from underlining interface

2023-06-11 Thread Vasiliy Tolstov
Yes, you are right. Mostly i'm worry about compile/run time. As i see on my mac air m1 compilation on go 1.20 slowdown to 1-2s (i think because file parsing) And don't know about running time of such checks for many interface implementations... I'm try to check in number of interfaces in

[go-nuts] Re: smarter way to provide interface capabilities from underlining interface

2023-06-11 Thread Brian Candler
I think the issue is that the *consumer* of this object checks whether certain methods (or rather, interfaces) are present, and behaves differently depending whether they are or not. There are a whole load of public interfaces defined here:

[go-nuts] Re: smarter way to provide interface capabilities from underlining interface

2023-06-11 Thread Tamás Gulácsi
As Far as I See, you check all the combinations of methods in wideness order. Why not have a generic wrapper struct, that is filled with the underlying driver.Conn's methods, and use that if not nil, but use the generic implementation if not. Like ``` type wrappedConn struct { driver.Conn