Comments (1)
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?
from protoreflect.
Related Issues (20)
- EnumBuilder panics if it contains EnumValue with explicitly set Number HOT 1
- might not be bug: false duplication report due to use of relative path instead of absolute path HOT 6
- SIGSEGV: panic: runtime error: invalid memory address or nil pointer dereference in v1.15.2 HOT 8
- Protoreflect doesn't fall back to to v1alpha when a gRPC unimplemented response is returned HOT 1
- String escaping in protoprint is wrong HOT 1
- First enum value must be 0 in proto3 [protoprint] HOT 2
- missing `{}` after printing option HOT 5
- Upgrade protocompile to v0.7.0 HOT 3
- go build error HOT 3
- Regression upgrading from v1.14.1 to v1.15.4: extensions are resolved recursively instead of non-recursively HOT 1
- Regression upgrading from v1.14.1 to v1.15.4: absolute paths no longer accepted by parser.ParseFilesButDoNotLink HOT 3
- Regression upgrading from v1.14.1 to v1.15.4: new mustBeSource constraint/check HOT 5
- Stub structure and Methods will relay on protobuf API V2 HOT 15
- Fail to compile proto file HOT 2
- Tests broken with google.golang.org/protobuf v1.33.0
- If there are messages nested in the proto file, the numbers will be recognised as strings HOT 2
- invalid memory address or nil pointer dereference HOT 5
- will return Symbol not found when the proto file has enum definition HOT 1
- Is there a way to UseProtoNames? HOT 2
- desc/builder: feature request: auto-de-duplicate builders and already-built descriptors in transitive graph HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from protoreflect.