[
https://issues.apache.org/jira/browse/THRIFT-4496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16525021#comment-16525021
]
ASF GitHub Bot commented on THRIFT-4496:
----------------------------------------
jeking3 edited a comment on issue #1567: THRIFT-4496: python specific list of
keywords for python generator
URL: https://github.com/apache/thrift/pull/1567#issuecomment-400661631
Another concern I see is that if we do not check for a complete list of
keywords during compilation for all languages, when someone wants to add a new
language to their build they might run into a problem later on with a
language-specific violation. Fortunately Thrift uses the identifying number
and not the name of the item for fields, but not so for names of structures,
etc. So it is possible someone might run into issues in the future adding
output for more languages and need to change their thrift file, and need to
change other implementations.
Mitigation for this will be to get a list of keywords into every
compiler-language implementation and instruct folks to generate code for each
language they expect to use, to check for keyword violations early.
It's still not exactly how Thrift is supposed to operate, which is to offer
the lowest common denominator across all languages, which really leads us to
want to put the entire list of reserved keywords into the .ll file as they
were, but grow the list to include keywords for all languages.
I'd like to hear from some other long-time thrifters on this approach and
see what they think... should the list of language keywords be language
specific or global? Should we perhaps have the list of keywords be additive in
the compiler code so that we end up with one big list we're checking regardless
of language output?
I like the idea of keeping the keywords in language-specific implementation
files, but perhaps when the compiler starts up it should load them from all the
languages and check them. It could even be smart enough to identify the
language the keyword is used in so that the output message can be more
specific, i.e. "sample.thrift:46: portability violation: keyword 'true' is
reserved by cpp, lua, perl, php and cannot be used here." (just an example, may
not be correct).
That could be done with a std::map<std::string, std::set<std::string> >
where the value is a set of language names that reserve the keyword and this
map would be updated by each compiler language implementation as it is loaded.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> Dealing with language keywords in Thrift (e.g. service method names)
> --------------------------------------------------------------------
>
> Key: THRIFT-4496
> URL: https://issues.apache.org/jira/browse/THRIFT-4496
> Project: Thrift
> Issue Type: New Feature
> Components: Compiler (General)
> Reporter: Vera Filippova
> Priority: Minor
>
> Apache Thrift compiler doesn't allow to use keywords in any of supported
> languages as field names. However, there are other compilers, like Scrooge,
> which do allow using some keywords as field identifiers, which leads to
> incompatibility.
> Assume we had a service with 'delete' method, with Java code generated by
> Scrooge. Now we'd like to generate Python code with Apache Thrift, but
> encounter an error because of the 'delete' keyword.
> I understand that using only Apache Thrift compiler, a user will never
> encounter this problem, but I think enabling keywords by request seems
> feasible.
> h1. Proposal
> It's possible to tweak keywords on code generation stage, e.g. use 'delete_'
> as a name of a generated function instead of 'delete', then use the original
> method name for a protocol message: writeMethodBegin('delete').
> This feature could be enabled with an additional flag, e.g. --screen-keywords.
> I have a draft for python generator here [https://github.com/nsrtvwls/thrift]
> The questions are, is this functionality welcome? If yes, would it require to
> have it supported for all languages?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
