Objective-C Filename Prefix from objc_class_prefix

293 views
Skip to first unread message

Ray Scott

unread,
Aug 3, 2017, 5:34:07 AM8/3/17
to Protocol Buffers
Hi, 

I'm new to Protocol Buffers, and I'm using gRPC within a iOS Framework written in Objective-C. I found the useful proto3 option, objc_class_prefix, for adding a 3+ character class prefix to the Objc generated code. What I don't understand is why this class prefix (for e.g. "MYRPC") isn't used to name the generated pbobjc.h & pbobjc..m files too. 

The only way I've found to get around this, unacceptably, is to append to the snake case name so the file named "m_y_r_p_c_service.proto" is converted to MYRPCService.pbobjc.h & MYRPCService.pbobjc.m. Of course, if you change the protobuf option objc_class_prefix in the source, you'd still need to rename the files. Plus, if I use these proto files to generate code for a different language, the file naming convention may not be the same as for Apple's Obj-C convention. 

Considering it's good style (and something Xcode does automatically) to name your objc files with the class prefix, I would have thought this would have applied to the generated source code files with protobufs. 

Does anyone know how to achieve this file name prefixing without the .proto file name hack?

Thomas Van Lenten

unread,
Aug 3, 2017, 9:33:50 AM8/3/17
to Protocol Buffers
The prefix is documented to only be added to the symbols created within the file, it does not change the name of the file.  The compiler with recreate the file hierarchy it is given, so the files should be unique, and the prefix isn't needed from that pov.  Generally speaking, having something within the file change what files are generated makes things very difficult to integrate with build systems as build systems don't want to have to know how to parse/inspect all the files they may pass off to tools.  The fact that we do the camel case transform has already been flagged as an issue, but it would break things to change that behavior at this point.

Ray Scott

unread,
Aug 3, 2017, 10:20:53 AM8/3/17
to Protocol Buffers
Or, you could make better use of your own options with a 

objc_filename_style=[none || camel]
objc_prefixed_filename= [no || yes]

Now everyone wins. :-)

Thomas Van Lenten

unread,
Aug 4, 2017, 9:57:56 AM8/4/17
to Protocol Buffers

On Thursday, August 3, 2017 at 10:20:53 AM UTC-4, Ray Scott wrote:
Or, you could make better use of your own options with a 

objc_filename_style=[none || camel]
objc_prefixed_filename= [no || yes]

Now everyone wins. :-)

Do you mean a file option?  That would still be within the file, so it has the same problems, no?

TVL

Ray Scott

unread,
Aug 4, 2017, 12:18:14 PM8/4/17
to Protocol Buffers
I don't know the internals of the protobuf architecture with respect to plugins, or the compilation process, so I don't know where or why the output source filename gets set.  I just know it would be useful to be able to configure the resulting filename format.

Thomas Van Lenten

unread,
Aug 5, 2017, 12:24:37 PM8/5/17
to Protocol Buffers

On Friday, August 4, 2017 at 12:18:14 PM UTC-4, Ray Scott wrote:
I don't know the internals of the protobuf architecture with respect to plugins, or the compilation process, so I don't know where or why the output source filename gets set.  I just know it would be useful to be able to configure the resulting filename format.

My point was, if you are talking a file options (like prefix), it would be within the file, so it would have the same problem, something that is within the file changing what is generated, so just like a build system can't read the prefix, it wouldn't be able to read that option either.

TVL
Reply all
Reply to author
Forward
0 new messages