ni / grpc-device

gRPC server providing remote access to NI device driver APIs.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Attribute enum values starting with S get mangled by C# protoc generator

astarche opened this issue · comments

Reported by @smooresni

PecificDriverDescription

This happens because our attribute prefix (NIRFSA_ATTRIBUTE) does not match the attribute name (NiRfsaAttributes). Normally this would defeat the nice-to-have prefix stripping in the C# client generator. But when the value starts with S the prefix-stripping works and takes the S off with it.

AB#1728728

More info in protocolbuffers/protobuf#9138 .

If we can get the issue fixed in protobuf, we'll get the reasonable-but-long untrimmed enum names like the one in the top of the screenshot (NiRfsaAttributes.NirfsaAttributeUserSourcePulseWidthUnits).

Prefixing enum names is definitely a best practice, and the convention (in linters and docs) is to use the ENUM_NAME as the prefix. The specific reasoning is to avoid conflicts, although that doesn't explain why you'd need the exact same name. Now we know two good reasons to follow that convention!

If we can't get it fixed, and assuming we don't want to live with C# clients getting nonsense names for all S attributes: we need to change the names. I propose changing the enum name to remove the s. This would also have the advantage of getting the trimmed names for the entire enum: I.e., NiRfsaAttribute.UserSourcePulseWidthUnits.

For compatibility, we could duplicate the enum (with the corrected name) and add an attribute_v2 field to the affected messages.

We typically prefix the enum names correctly. But there's another exception for attribute values I.e.,
"NISWITCH_INT32_WIRE_MODE_VAL_1_WIRE" is expected to have the prefix "NI_SWITCH_INT32_ATTRIBUTE_VALUES_". Those are out-of-convention and would miss the name-shortening convenience of the C# generator. On the other hand, those names are already crazy long (they're effectively double-prefixed), and matching the prefix would make the python/c++ field names even longer. Also none of those values would be susceptible to this specific mangling issue. I'd expect them to be pretty safe, but being out-of-convention can have unexpected consequences.

FYI @harsha-bhushan @ccifra