Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

desc: GetFullyQualifiedName should return names that lead with a "." #151

Closed
spenczar opened this issue Aug 31, 2018 · 1 comment
Closed

Comments

@spenczar
Copy link

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 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.

@jhump
Copy link
Owner

jhump commented Aug 31, 2018

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?

@jhump jhump closed this as completed Sep 8, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants