Add a CLI flag to disable the snake_case conversion of message and signal names #255
Conversation
There was a problem hiding this comment.
it would probably be better move the stuff which concerns itself with C code generation out of the database part of the codebase into the relevant subparser? (side note: the class names here are quite confusing, IMO.)
besides this, the patch seems to be fine...
| @@ -536,9 +536,13 @@ | |||
|
|
|||
| class Signal(object): | |||
|
|
|||
| def __init__(self, signal): | |||
| def __init__(self, signal, disable_snake_case_conversion): | |||
There was a problem hiding this comment.
it is probably slightly better to use a "positive" name for the parameter, e.g. use_raw_names?
|
What's the status of this PR? I'm interested in it being merged |
it currently has some merge conflicts with master... |
Co-authored-by: Andreas Lauser <github@poware.org>
|
... and it would be nice if the functionality was featured by a unit test. Besides this, I don't see an reason not to include this functionality. (It looks like this PR was left unmerged because the discussion does not seem to be finished, then it started to suffer from bitrot after a while...) |
|
So we are missing unit test and it can be merged? |
plus a rebase on top of the latest master... |
|
If the original author of the PR doesn't rebase, can someone else do it? |
yes. just make a new PR and mention that it is based on this one... |
We have a use case in which we wish to preserve message and signal names in the original form in the generated C source code. This PR adds a CLI flag that disables the default behaviour of converting all message and signal names to snake_case.
It ads a guard around each use of
camel_to_snake_case(). Ifdisable_snake_case_conversionis true then we only perform the_canonical()sanitation. It also changesself.snake_nametoself.exported_namefor messages and signals.A cleaner solution would be to create a
generatorclass which stores the settings for the generation, and make all generator functions methods of the new class, rather than passing the new argument into every function in the call tree that includescamel_to_snake_case, but that would be a bigger architectural change.If this is a change that other people are likely to find useful, let me know and I'll finish off this PR. As it stands we'll probably continue to use my fork internally.