Use camelCase for object properties about protobuf.js HOT 11 CLOSED

If there isn't a bug that I don't know of, then for a field named "id" there should are already be these three options:

• getId() / setId(...)
• get_id() / set_id(...)
• direct access to id

from protobuf.js.

I meant multi-word field names, such as something_id.

from protobuf.js.

So, if you name it "somethingId", you should be able to access it through:

• getSomethingId() ...
• get_somethingId()
• and of course direct access to somethingId

And if you name it something_id:

• getSomethingId()
• get_something_id()
• direct access to something_id

Or am I getting something wrong?

Relevant part: https://github.com/dcodeIO/ProtoBuf.js/blob/master/src/ProtoBuf/Reflect.js#L450

from protobuf.js.

Protobuf fields normally use camel_case, as per the convention, and the .proto file might be coming from an external source. What I'm suggesting is being able to access a something_id field using somethingId (and construct a respective Message using a key named as such).

from protobuf.js.

I see. The current way it is done is through the getters and setters that are available both in camelCase as well as in under_score notation. The field itself is accessed through the exact naming and at least I am feeling comfortable with that, for the following reason: The problem here is if let's say you have an external proto file that doesn't stick to the convention and uses both some_thing and someThing (for whatever reason) as two seperate fields, then it would still be possible to access these fields properly through direct access while getters and setters, which are an optional convenience addition, would refer to the first field only. Imho this is the most straight forward way to handle this exact case.

from protobuf.js.

Such a .proto file would break the official Java implementation. In the very unlikely event that someone encounters this, they can resort to editing their copy of the file.

from protobuf.js.

Or here's an alternative approach. You could store field values in "private" properties, e.g. _some_thing and _someThing (preferably defined with Object.defineProperty to make them non-enumerable). That way, both of them would be accessible with (get|set)_some_thing and (get|set)_someThing methods respectively. someThing and some_thing would both be accessor properties to _some_thing.

from protobuf.js.

I am sorry but I am still not sure if it's worth the trouble of breaking compatibility eventually...

from protobuf.js.

I'm not sure what you mean by breaking compatibility. If you mean compatibility with previous ProtoBuf.js versions, then it would break only in the following two cases:

1. Someone has a .proto file with a message that defines both some_thing and someThing and accesses the fields using some_thing and someThing properties respectively. With my original suggestion, they would need to modify their .proto file, but with the alternative approach, they would have to change their code to access the latter field using get_someThing and set_someThing. Chances that this will affect any current ProtoBuf.js users are virtually none.
2. Someone has a .proto file that defines any camelCase fields (say, someThing) and accesses them using get_ and set_ methods, which currently convert the field name into snake_case (i.e. get_some_thing and set_some_thing). If you go with the alternative approach, they would need to use either (get|set)someThing, or access it using the property (someThing), since the get and set_ methods would need to preserve the field's actual name. Again, very unlikely to affect anyone, because: 1) I've never seen a .proto file with camelCase fields and 2) why anyone would access said fields using snake_case methods is beyond me.

And if you mean compatibility with other Protobuf libraries (excluding chrisdew's protobuf and the official Java implementation), then that would be preserved with the alternative approach.

from protobuf.js.

Hmm... sorry, but I am not convinced. If you actually prefer namings in camal case for your self, you should change the .proto files instead. We shouldn't break compatibility for a convenience function like that and we already have both getters and setters around.

What you however could do would be to implement an alternative constructor, a constructor flag that converts camel cased object keys into the matching underscore representation explicitly or a global property on the protobuf namespace, i.e. by specifying a field like "$convertFieldsToUnderscore": true or a property ProtoBuf.convertFieldsToUnderscore = true and I could incorporate it into the master branch.

See: https://github.com/dcodeIO/ProtoBuf.js/blob/master/src/ProtoBuf/Reflect.js#L374

from protobuf.js.

How about a ProtoBuf.convertFieldsToCamelCase property instead, that would do both what you have suggested and what I had proposed?

from protobuf.js.