-
Notifications
You must be signed in to change notification settings - Fork 570
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
Emit a public constructor for each generated message #136
Conversation
// private SimpleMessage(Builder builder) { | ||
// super(builder); | ||
// this.optional_int32 = builder.optional_int32; | ||
// } | ||
// | ||
private void emitMessageConstructor(MessageType messageType) throws IOException { | ||
private void emitMessageBuilderConstructor(MessageType messageType) throws IOException { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we eliminate this altogether? It looks like both need to perform the necessary sanitization of inputs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only tricky part is passing the Builder's unknownFieldMap into the Message's constructor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, right. I always forget about that guy. I think it's fine as-is then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally don't think that's worth it. I'm looking forward to initializing my one or two-field messages with new Foo(bar, baz)
and the overhead of one method per-type is worth it to me.
For extremists we could even offer a --no-builders
option on the compiler.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think two constructors is the best choice, but would like to find a way to eliminate the duplication of the sanitization work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good. Is that just calling this(builder.foo, builder.bar);
and then doing the unknown field map?
LGTM! One nit and one question about killing the private ctor. |
LGTM! |
Emit a public constructor for each generated message
Not sure what LGTM means but this is pretty sweet. Can I pick this up in a snapshot version? |
LGTM = looks good to me You can clone the repo and do 'mvn install' locally. Then your upstream project can depend on Wire 1.5.1-SNAPSHOT. |
Wanted to note that 1.5.1-SNAPSHOT has issues. Attempted to build it and some tests fail. Built with -DskipTests and it built but the generated code has a bunch of compile errors. Anybody else seeing this? |
Nope: https://travis-ci.org/square/wire Are you using Java 7 or Java 8? |
Java 1.7.0_45 |
@ocean7 would you be willing to paste the test failure output here? |
C:\data\projects\wire\wire-runtime\src\main\java\com\squareup\wire\BuilderAdapter.java:0: File does not end with a newline. Perhaps some kind of encoding issue? |
Looks like it could be related to Windows encoding. Can you provide more context as to what phase of the build is producing this output? If you like you can paste the entire output into a Gist. |
Not sure how to post a gist...
|
If it is a Windows encoding issue I'll look into how to specify a specific encoding for the build. Seems like maven builds are supposed to define their project encoding anyways. Something to do with this common error perhaps: http://maven.apache.org/general.html#encoding-warning ? |
@ocean7 please make the following change to the checkstyle.xml file and re-run. Let me know if the build succeeds. Basically you will be removing the line
|
Fixed one problem, but alas another.
|
@ocean7 there are many places that we assume a file separator character of |
Sure would be happy to try and get this fixed. (Would really like to use ctors for message construction.) Do you want to create a branch that I can clone and build on? I deleted WireCompilerTest.java and WireCompilerErrorTest.java and was able to build and install. I still get this problem where the generated code is trying to call to a Message constructor that doesn't exist. For example I have a message:
The super(builder) call has a compiler error:
The Message class in 1.5.1-SNAPSHOT has no ctor that takes a constructor. Instead (looking at the bytecode in Eclipse) it seems to have a default ctor and a protected setBuilder(Builder) method. So for some reason (putting aside the test that I can just delete) the maven plugin is still generating uncompilable code. |
@ocean7 can you make sure all your old generated code has been removed before building? We should not be generating a call to Try building with the flag |
Code generation itself is failing with messages like:
So it seems to be generating that code. The pom file looks like:
Nothing terribly special... |
@ocean7 would you mind testing out the I'll try out your pom to see if I can reproduce the error above. |
@ocean7 can you send me the whole pom.xml as well as your dictionary.proto file? You can email to rice@squareup.com. |
Fixes #135.