Hi, no, there isn't really a solution to this. I've blogged about this: https://blog.merovius.de/2017/07/30/the-trouble-with-optional-interfaces.html A combination of generics and embedding can help. So, you can do
type Wrapper[T] struct { T otherFields } func (w *Wrapper) SomeNewMethod() { } But even then, you need to know the static type of what you're wrapping (so http Middleware, for example, couldn't use this). I'm also not super sure if it's a good idea to do this even if you could. An interface might contain multiple, interdependent methods. As an example, `http.ResponseWriter` implicitly calls `WriteHeader` the first time you call `Write`. So, if you wrap a `ResponseWriter` and overwrite `WriteHeader`, that overwritten method has to be called explicitly (the underlying `ResponseWriter` will call its own `WriteHeader`). So if you don't know what the methods of the wrapped type are and do, you might introduce very hard to find bugs. On Wed, Aug 26, 2020 at 5:49 PM cpu...@gmail.com <cpui...@gmail.com> wrote: > Hi All, > > using interfaces for behavioural testing seems a common pattern in go: > > if typed, hasCapability := d.(Capability); hasCapability... > > I have the requirement to dynamically compose interfaces at runtime, i.e. > I cannot know upfront which set of interfaces a resulting type will support: > > type resultingType interface { > basicCapability > ...any combination of additional capabilities > } > > If there is only a single additional/optional capability to implement that > is simple to solve, e.g. by implementing a wrapping struct that embeds the > basic capability and adds an additional capability. Applying this pattern > across multiple layers (stack of wrapping structs does not work as the > embedded interfaces don't bubble up). > > However, the number of additional capabilities that a type might have to > support could be bigger (think of physical meters which could supply power, > energy, currents, frequency etc). > > I'm solved this by using go:generate which is fed the basic and set of > optional types and generates additional types for any _combination_ of > additional types, an example is attached (and source at > https://github.com/andig/evcc/pull/310/files#diff-fa40c05651b4682eb25a198f8a4a98f0). > This is similar to the "old" pattern of simulation generics via generated > code. > > I'm wondering if using a pattern of dynamic composition is sound, if the > the go:generate approach is a good one or if there are better ways? > > Kind regards, > Andi > > -- > 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/217cee40-1e00-442d-a4d2-7d4a37e41544n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/217cee40-1e00-442d-a4d2-7d4a37e41544n%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/CAEkBMfEQq%2BErDOGbX5jD1PrnZQdrYut_E6zajRpYYbM3NiBe1g%40mail.gmail.com.