You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At least for Messages in the desc package (and probably for other types, but I'm not sure), the GetFullyQualifiedName() method currently returns values that lack a leading dot, so they aren't actually fully-qualified.
This is a twin issue to #150. Copy-pasting from there:
Leading dots are the way that a symbol is unambiguously marked as fully-qualified in proto source code, since the proto languages allows you to refer to types in a less-than-fully qualified manner. The value returned by this function includes all of its enclosing namespaces, including the package, so it is fully qualified.
I don't agree that this should emit the leading dot, and there is plenty of prior art in the actual protobuf runtime with which this is consistent (such as this and this).
Also worth pointing out that this change would not be compatible with existing code that expects current implementation, and its value is quite unclear. Unless you are writing a name resolver that supports a namespace context and unqualified names, it's not necessary (or useful?) to include the leading dot. You know it's fully-qualified because the Go doc says so.
This is also documented in FieldDecriptorProto.
That documentation is specifically for value of the type_name field of FieldDescriptorProto.
Could you be more specific about why you think this is valuable or necessary?
At least for Messages in the
desc
package (and probably for other types, but I'm not sure), theGetFullyQualifiedName()
method currently returns values that lack a leading dot, so they aren't actually fully-qualified.This is a twin issue to #150. Copy-pasting from there:
Leading dots are the way that a path specification is marked as fully-qualified, as documented in the parser: https://github.com/protocolbuffers/protobuf/blob/ba8692fbade4ba329cc4531e286ab5a8e0821d97/src/google/protobuf/compiler/parser.cc#L2157
This is also documented in FieldDecriptorProto.
The text was updated successfully, but these errors were encountered: