Some way to reflect on a message's fields about protobuf.js

[dcodeIO]

See: https://github.com/dcodeIO/ProtoBuf.js/wiki/Reflection

Let me know if this is helpful and feel free to ask questions.

[seishun]

Thanks for the quick response.

This works, but a simpler API would definitely help. For example, it's not clear from the documentation that you are supposed to use the resolvedType property to get at a nested message's reflection, and it seems the only way to get to the actual Message class from its reflection is to use the undocumented built property. Let me know if I'm missing something.

[dcodeIO]

3a78cec

Thank you for your suggestions. I've changed the API a bit to use more intuitive names. What was built before now is clazz in the context of messages and object in the context of enums. It's also no longer inherited from Reflect.T. Regarding resolvedType, i've added that together with clazz and object to the reflection docs. However, this could possibly break existing programs using ProtoBuf.js at the reflection level, so I've decided to make this v1.1.0.

Please review it again and let me know what you think!

https://github.com/dcodeIO/ProtoBuf.js/wiki/Reflection

[seishun]

Thanks, this is exactly what I was looking for.

Another point worth mentioning is that Builder#lookup() works differently from Builder#build() without an argument. While the former returns a Namespace object, the latter returns a name->type map, which I think is more useful, since key lookup is faster than iteration over an array (which, if my understanding is correct, is what happens internally when you provide an argument to lookup).

[dcodeIO]

Yes, it's not exactly the same but similar. The recommended way to work with still is Builder#build, while Builder#lookup should be used only if reflection is actually required.

In the process of parsing, building and en/decoding, which is all sequental (name lookups need to be done only once), the array structure of the internal types is more efficient.