4 ms·
Hmmm. I can see how adding methods to a type in a different package would require that package to be recompiled, but I don't see how I could break that package.
by GhotiFish 14y ago
Hmmm. I can see how adding methods to a type in a different package would require that package to be recompiled, but I don't see how I could break that package. Unless there's some reflection magic I'm not considering.
I'm reading through the embedded types now. I am new to golang so this one is lost on me. I thought if you wanted your own methods on a type from another package, you just aliased it with your own type def.
though it looks like there's some kinda prototyping behavior being described here?
If S contains an anonymous field T, the method sets of S and *S both include
promoted methods with receiver T. The method set of *S also includes promoted
methods with receiver *T.
If S contains an anonymous field *T, the method sets of S and *S both include
promoted methods with receiver T or *T.
- Jabbles 14y agoFor example, if you do a runtime type assertion to see if a variable satisfies an interface: v, ok := x.(T) http://golang.org/ref/spec#Type_assertions http://golang.org/ref/spec#Type_assertions If you "monkey-patch" x to satisfy T in another package, the value of ok may change.
- GhotiFish 14y agoHmm I can kind of see what you mean, but I don't see it as a big of a problem. If you make package A depend on package B, package B monkey-patches x with method Foo so now x is a Fooer x now satisfies the Fooer interface in package A, well that seems ok. You imported B after all. In things that don't import B, x doesn't satisfy Fooer. Is this unexpected behavior? If B depends on C, C's x won't satisfy Fooer right?