Skip to content
This repository was archived by the owner on Dec 23, 2023. It is now read-only.

Conversation

@dinooliva
Copy link
Contributor

If we decide to go with this change, there will be a dual change to deserialize to take an InputStream rather than a ByteBuffer.

* @return the given {@link OutputStream}
*/
public abstract ByteBuffer serialize();
public abstract OutputStream serialize(OutputStream output);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this be void?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have it return the output stream in case someone wants to chain calls together.

I am thinking of adding a 'throws IOException' in case writing to the stream has a problem.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have it return the output stream in case someone wants to chain calls together.

IMO a void return type makes it clearer that the method writes to the input, and that the user doesn't need to look at the return value.

.newBuilder().setTags(builder.toString()).build().toByteArray());
try {
output.write(StatsContextProto.StatsContext
.newBuilder().setTags(builder.toString()).build().toByteArray());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can call StatsContextProto.StatsContext.writeTo(OutputStream) now.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice.

Copy link
Contributor

@sebright2 sebright2 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we keep the old serialization methods, too?

@dinooliva
Copy link
Contributor Author

I don't think there's any point to - we don't need them for backward compatibility so we're probably better off getting rid of them entirely.

@dinooliva dinooliva merged commit 5f551bd into census-instrumentation:master Dec 7, 2016
@dinooliva dinooliva deleted the serialize branch December 7, 2016 21:25
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants