If we were to send
type ABC struct{
i interface{}
}
gob requires us to register the concrete type hidden behind our interface{}.
Why can't gob use reflection to identify the underlying concrete class in the field by itself.
That is, we need to use the Register method to tell gob what the concrete type is.
Given the method signature looks like this Register(value interface{}), gob already uses reflection to fully identify the type passed to the method.
Why doesn't gob iterate through the instantiated ABC struct at runtime and perform Register automatically?
Related
I'm currently studying Go and trying to understand the concept of Interfaces.
What I understand about it is that whatever type implements the functions specified in the interface is part of it.
My question is about the Body of type io.ReadCloser inside of the Response struct. How does it implement the Read function? I've searched through the documentation and couldn't find it.
io.ReadCloser does not implement the Read function. io.ReadCloser is an interface type, so it by itself cannot implement any methods. However, an interface T can implement another interface I if T's type set is a subset of I.
The io.ReadCloser interface embeds the io.Reader and io.Closer interfaces. Therefore the method set of io.ReadeCloser is the combined method set of io.Reader and io.Closer.
Thanks to embedding the type set of io.ReadCloser is the intersection of io.Reader's and io.Closer's type sets. In other words the type set of io.ReadCloser is the set of all types that implement the io.Reader and io.Closer interfaces.
The above also means that the type set of io.ReadCloser is a subset of io.Reader's type set and io.Closer's type set.
The io.ReadCloser interface implements io.Reader because:
A type T implements an interface I if
T is not an interface and is an element of the type set of I; or
T is an interface and the type set of T is a subset of the type set of I.
I have a custom type, which is supposed to be an enumerator, and it implements json.Unmarshaler.
When I unmarshal into a slice, or a struct of this type, it works, like https://go.dev/play/p/DGg3nzo_VwN
When I unmarshal into a map containing this type, it breaks, like https://go.dev/play/p/YGgnRvr0agz
Crawling through the source code (go 1.18), I know how to make it work, just implement encoding.TextUnmarshaler, like https://go.dev/play/p/vY4E4snAY52 and I also have learned how the code works for maps: it checks if encoding.TextUnmarshaler is implemented, if yes, call its UnmarshalJSON before trying UnmarshalText. In other words, UnmarshalText must be present, however it will be ignored if UnmarshalJSON is also present.
Why is this precedence? Why only maps are treated this way?
From Go's decoder:
// Map key must either have string kind, have an integer kind,
// or be an encoding.TextUnmarshaler.
So you must implement TextUnmarshaller.
I have a map that uses an interface as the key. The map is defined like this MyMap map[Signature]Packets. The interface is Signature, and there will be two structs A and B that implement this interface. I am also using msgp to serialize these two structs.
My issue is that msgp automatically generates methods that use a pointer as the type of the function receiver, which I think will make the key Signature receive pointers. If that was the case, then the key would be different every single time since pointers are different, even though the underlying values are the same. So, every time, I would be creating a new entry instead of finding the existing one and modifying it.
I wonder:
Is there a way to force msgp to generate methods purely with function receivers of the concrete type? Currently, I can only modify the function receivers of auto-generated methods like MarshalMsg and UnmarshalMsg to the concrete type (A or B instead of *A or *B). By doing that, the key of the map is either of type A or of type B, and the map MyMap works fine. However, I know I should not modify the auto-generated code. So, I wonder whether there is an acceptable way to do that.
If there is no way to do 1., is there any workaround to solve this problem? I really need some polymorphic feature of the map's key with the use of msgp.
UPDATE 1 (Apr. 12):
Thanks for sharing your thoughts and offering solutions. Here are some details about my question.
The background is that the map is used for collecting different network events. The two structs implementing the interface Signature are EventSignatureIPv4 and EventSignatureIPv6
type EventSignatureIPv4 struct {
SourceIPv4 [4]byte
Port uint16
Traffic TrafficType
}
type EventSignatureIPv6 struct {
SourceIPv6 [16]byte
Port uint16
Traffic TrafficType
}
and Signature is holding common methods shared between IPv4 and IPv6 data. So, essentially, I want to collect and group corresponding IPv4/v6 events at the runtime. The key of the map is to identify the same source, and the value of the map is to collect events with different destinations.
The msgp library I am using is this one https://pkg.go.dev/github.com/tinylib/msgp#v1.1.5/msgp
Correct me if I am wrong. For compositions in Go, if one of the methods in the method set has a function receiver of the pointer type, then the instance would only be of the pointer type? So here, as I have
func (z *EventSignatureIPv6) MarshalMsg(b []byte) (o []byte, err error) {
/* Auto-generated code */
}
whenever I use Signature to receive the struct EventSignatureIPv6, the struct would only be of type *EventSignatureIPv6?
You are right, "two pointer values are equal if they point to the same variable.", so if you are looking to compare interfaces that may hold pointers to different types, e.g. *A and *B, you are already in trouble.
With that said, I don't think it's an amazing idea to use interface types as map keys in the first place, because you have to deal with some caveats, the first is that:
The comparison operators == and != must be fully defined for operands of the key type
And now you need to be careful about the types that implement the interface. In theory, nobody stops a client from implementing your interface on a defined type with underlying unhashable type, e.g. type UncomparableSignature []int
So you would probably have to add an unexported method on your interface, so that client code outside that package can't implement it. But still, nothing stops code within the same package from implementing it, so this is, at best, maintenance overhead.
Then if the interface holds pointers to zero-values, it's even dependant on the implementation of the specs:
Pointers to distinct zero-size variables may or may not be equal.
Furthermore, you open yourself up to pesky bugs, like variables of type Signature that holds a nil will overwrite each other's values:
var foo Signature
var bar Signature
myMap[foo] = &Packet{/*pretending to have value 1*/}
myMap[bar] = &Packet{/*pretending to have value 2*/}
fmt.Println(myMap[foo]) // 2
A possible solution is, you could replace the map key with a unique id, and you enforce implementors to provide it by declaring the appropriate method on the interface Signature (this still assumes that the implementors can be coordinated to provide unique ids across all of them):
type Signature interface {
UniqueIdent() uint64 // or string, if you prefer
// ...other methods
}
and then
packet := myMap[someSignature.UniqueIdent()]
I am actually learning golang (from .NET) and there is one thing I don't understand about this language.
Sometimes I find this kind of declaration:
https://github.com/golang/crypto/blob/master/ed25519/ed25519.go
// PublicKey is the type of Ed25519 public keys.
type PublicKey []byte
What does it mean exactly?
Is it a creating a struct which inherit from []byte?
Is it just an alias?
I thought golang forbid inheritance.
It's a type declaration, more specifically a type definition. It creates a new type, having []byte as its underlying type:
A type definition creates a new, distinct type with the same underlying type and operations as the given type, and binds an identifier to it.
New types are created because they can simplify using them multiple times, their identifier (their name) may be expressive in other contexts, and–most importantly–so that you can define (attach) methods to it (you can't attach methods to built-in types, nor to anonymous types or types defined in other packages).
This last part (attaching methods) is important, because even though instead of attaching methods you could just as easily create and use functions that accept the "original" type as parameter, only types with methods can implement interfaces that list ("prescribe") those methods, and as mentioned earlier, you can't attach methods to certain types unless you create a new type derived from them.
As an example, the type []int will never implement the sort.Interface required to be sortable (by the sort package), so a new type sort.IntSlice is created (which is type IntSlice []int) to which the required methods are attached, so you can pass a value of type sort.IntSlice to the sort.Sort() function but not a value of type []int. Since sort.IntSlice has []int as its underlying type, if you have a value of []int, you can simply convert it to sort.IntSlice if you want to sort it, like in this example (try it on the Go Playground):
is := []int{1,3,2}
sort.Sort(sort.IntSlice(is))
fmt.Println(is) // Prints: [1 2 3]
When you create a new type, there is no "inheritance" involved. The new type will have 0 methods. If you want "inheritance-like" functionality, you should check out embedding (in relation with struct types), in which case the embedder type will also "have" the methods of the embedded type.
I have 3 classes, which have several operation steps implemented in different functions. For example,
func ExternalAPI1() error
func ExternalAPI2(s string)
func internalProcess1() error
func internalProcess2(s []string) error
func internalProcess3(d int) error
For the internalProcessx, they're internal functions which may not be invoked by other classes, but these functions do have identical signatures.
Should I generate an interface for them with only ExternalAPI1 and ExternalAPI2 included? or should I include all these 5 functions in the interface?
tl;dr: don't worry about interfaces when creating structs, worry about interfaces when creating functions that would consume them.
The question overlooks an important underlying question: do you need an interface at all? I.e., is something going to accept values of the interface type, and operate on them without knowledge of the underlying type? If so, what methods will it call on the value? Those are the methods that should be in the interface.
Remember that Go uses duck interfaces; therefor, interfaces should be defined to suit the consumer, not the implementation. In fact, they should generally be defined alongside the consumer, not the implementation, because the implementation doesn't need to know anything about the interfaces it implements.
In Go, when a function or method can operate on "anything that implements method X", then alongside that function or method, you can define an "Xer" interface with that method signature. This allows anything to be passed to that function which meets the interface, and the function doesn't need to worry about what the underlying type is.
If you want the compiler to enforce that all structs which implement the interface have the unexported methods too, the unexported methods can certainly be included in the interface.
reflect.Type is an example from the stdlib (see here, godoc notes that the interface contains unexported methods)
An interface describes the methods required to perform a certain action. In your case, this is definitely the following:
type API interface {
ExternalAPI1() error
ExternalAPI2(s string)
}
However, do note that this does not limit the use of non-exported methods when using your struct (not class) directly from the same package.