Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Output types option (class vs struct) #14

Open
deviator opened this issue Feb 2, 2019 · 7 comments
Open

Output types option (class vs struct) #14

deviator opened this issue Feb 2, 2019 · 7 comments

Comments

@deviator
Copy link
Contributor

deviator commented Feb 2, 2019

I was edit an output files and change class to struct and no difference are detect. Have you any reason to use classes instead structs? Maybe it can be an option? But I don't know how to properly add this option to plugin command line or proto files.

Here I found no option for output types =(
https://github.com/dcarp/protobuf-d/blob/master/protoc_gen_d/protoc-gen-d.d#L150

@dcarp
Copy link
Owner

dcarp commented Feb 2, 2019

At the moment protoc_gen_d generates just classes. For small messages, as an optimization, you can replace class with struct and use value semantics.
Options probably could be used to control the class vs. struct generation, but I didn't thought much about it.

@deviator
Copy link
Contributor Author

deviator commented Feb 3, 2019

I try to write custom option by instruction:

syntax = "proto3";
package msg;

//import "proto_d/d_options.proto";

import "google/protobuf/descriptor.proto";

enum DMessageType {
    CLASS = 0;
    STRUCT = 1;
}

extend google.protobuf.MessageOptions {
    DMessageType d_message_type = 54321;
}

message OneData {
    option (d_message_type) = STRUCT;
    bool input = 1;
}

and added some debug output lines to protoc-gen-d.d

    private string generateMessage(DescriptorProto messageType, size_t indent = 0)
    {
        ...
        import std.stdio;
        stderr.writeln("options: ", messageType.options.toJSONValue.toPrettyString);
        ...
    }

and have no output (only options: {} and options: null).

From protobuf documentations:

Here we have defined a new message-level option by extending MessageOptions. When we then use the option, the option name must be enclosed in parentheses to indicate that it is an extension. We can now read the value of my_option in C++ like so:
string value = MyMessage::descriptor()->options().GetExtension(my_option);
Here, MyMessage::descriptor()->options() returns the MessageOptions protocol message for MyMessage. Reading custom options from it is just like reading any other extension.

but in descriptor.d in class MessageOptions no method getExtensions.

Proto3 support extensions only for custom options:

Note that creating custom options uses extensions, which are permitted only for custom options in proto3.

It's not implemented yet?

@deviator
Copy link
Contributor Author

deviator commented Feb 9, 2019

Other case of select struct vs class may be passing option to a cmd line of plugin, like this: protocolbuffers/protobuf#4759

I add output of input arguments in main of plugin:

int main(string[] args)
{
    import std.algorithm : map;
    import std.array : array;
    import std.range : isInputRange, take, walkLength;
    import std.stdio : stdin, stdout;

    import std.stdio;
    stderr.writeln(args);
    ...

and try to build my one.proto with this command:

protoc --plugin=protobuf-d/build/protoc-gen-d --d_out=source --d_opt=struct msg/one.proto

--d_opt=struct must pass struct in argument list of protoc-gen-d main function, but it don't. I get this output:

["protobuf-d/build/protoc-gen-d"]

What a curse is with D and protoc? I have no idea what I'm doing wrong...

@dcarp
Copy link
Owner

dcarp commented Feb 9, 2019

I think that plugin parameters are passed in the parameter member of CodeGeneratorRequest.

@deviator
Copy link
Contributor Author

deviator commented Feb 9, 2019

I think that plugin parameters are passed in the parameter member of CodeGeneratorRequest.

Oh... Thank you!

Maybe about options I made the same stupid mistake?

@dcarp
Copy link
Owner

dcarp commented Feb 10, 2019

From what I saw, I don't think that the options work with proto3.
I manually ported descriptor.proto to proto3. Protobuf documentation describes the option in context of proto3 using extend that is not present in proto3 anymore. It could be that there are some workaround in proto3, but even the description with proto2 looks quite cumbersome.

Maybe a simpler idea would be to use some special comments...

@mw66
Copy link

mw66 commented Oct 16, 2023

I think this option should be added to the README.

--d_opt=message-as-struct

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants