Open jufemaiz opened 3 months ago
Hi @jufemaiz, can you clarify exactly what the proposed resolution is here?
Would that change break any existing use cases?
There's two options, with one that I would lean towards due to Matz's language design.
#to_hash
as the default internally consistent method, but also expose #to_h
for direct use (whether this differs is a discussion more broadly if there is need for additional fields visible internalls).#to_hash
as an alias of #to_h
.Digging into this further, https://github.com/protocolbuffers/protobuf/blob/0302c4c43821ac893e8f1071576f80edef5c6398/ruby/lib/google/protobuf/ffi/internal/convert.rb#L190-L210 there's already a non-private #to_h
implementation (that #to_h
sometimes (?) directly calls), however the conventions of ruby are not being adopted, causing issues elsewhere there is an expectation of convention.
Please note that the ffi/
directory is an experimental implementation that is not currently the default. The default implementation is written in C: https://github.com/protocolbuffers/protobuf/blob/8d8db9cea8eb442a57286f33ec1e802c5d6c3149/ruby/ext/google/protobuf_c/message.c#L831-L840
I don't quite understand how options (1) and (2) are different. What's an example of how we might want #to_hash
and #to_h
to differ?
Ah fair enough on the ffi/
directory.
I am not sure why, but there may be reasons that the core team want a, by convention, internal function to differ from the external function. If there's no reason, aliasing one way or another would resolve the issue – and given the lack of implementation of #to_hash
I cannot imagine there would be a major issue in doing so.
Introducing #to_hash
as an alias of #to_h
seems reasonable to me.
How would you like to proceed on this? Changes to the c code?
What version of protobuf and what language are you using?
Version: main/v3.27.0+ etc. Language: Ruby
What operating system (Linux, Windows, ...) and version?
MacOS 14.5
What runtime / compiler are you using (e.g., python version or gcc version) Ruby v3.2
What did you do?
Build a library with it (or anything else). Then include it and build something containing a protobuf message. For example:
A key thing to note is this quote from Matz a decade ago:
ActiveSupport
rightfully makes use of the:to_hash
method for implicitly transforming anObject
to JSON format. Ref: https://github.com/rails/rails/blame/v7.1.3.4/activesupport/lib/active_support/core_ext/object/json.rb#L58-L66Unfortunately attempting to call
#to_hash
as opposed to#to_h
fails on protobuf messages. Aliasing#to_h
for#to_hash
calls seems a sensible option here in the absence of shifting the#to_json
method to also make use of#to_hash
as Matz implies is correct.What did you expect to see
First, when calling
#to_h
expect to see the marshalled hash even when nested. That is:Second, when calling
#to_json
expect to see the marshalled json, even when nested. That is:What did you see instead?
Make sure you include information that can help us debug (full error message, exception listing, stack trace, logs).
When calling
#to_h
:When calling
#to_json
:Anything else we should know about your project / environment
Possibly related to https://github.com/protocolbuffers/protobuf/issues/9500