mirror of
https://github.com/protocolbuffers/protobuf-go.git
synced 2025-01-01 03:14:16 +00:00
4b7aff630a
The terminology Vector does not occur in protobuf documentation at all, so we should rename the Go use of the term to something more recognizable. As such, all instances that match the regexp "[Vv]ect(or)?" were replaced. The C++ documentation uses the term "Repeated", which is a reasonable name. However, the term became overloaded in 2014, when maps were added as a feature and implementated under the hood as repeated fields. This is confusing as it means "repeated" could either refer to repeated fields proper (i.e., explicitly marked with the "repeated" label in the proto file) or map fields. In the case of the C++ reflective API, this is not a problem since repeated fields proper and map fields are interacted with through the same RepeatedField type. In Go, we do not use a single type to handle both types of repeated fields: 1) We are coming up with the Go protobuf reflection API for the first time and so do not need to piggy-back on the repeated fields API to remain backwards compatible since no former usages of Go protobuf reflection exists. 2) Map fields are commonly represented in Go as the Go map type, which do not preserve ordering information. As such it is fundamentally impossible to present an unordered map as a consistently ordered list. Thus, Go needs two different interfaces for lists and maps. Given the above situation, "Repeated" is not a great term to use since it refers to two different things (when we only want one of the meanings). To distinguish between the two, we'll use the terms "List" and "Map" instead. There is some precedence for the term "List" in the protobuf codebase (e.g., "getRepeatedInt32List"). Change-Id: Iddcdb6b78e1e60c14fa4ca213c15f45e214b967b Reviewed-on: https://go-review.googlesource.com/c/149657 Reviewed-by: Damien Neil <dneil@google.com> |
||
|---|---|---|
| .. | ||
| convert.go | ||
| list.go | ||
| map.go | ||