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

C# Proto2 feature : Extensions #5350

Conversation

ObsidianMinor
Copy link
Contributor

We're at the final stretch.

This PR adds support for extensions in the C# library and code generator.

Copy link
Contributor

@anandolee anandolee left a comment

Choose a reason for hiding this comment

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

Nice we are close to proto2!

@anandolee
Copy link
Contributor

Can you also make sure this PR is work with C# 6.0? We've got an issue for C# 6.0 compatible, and was working on it in #5445

@ObsidianMinor
Copy link
Contributor Author

Sure but after #5445 is pulled so i can rebase on top of it.

@ObsidianMinor
Copy link
Contributor Author

Now C# 6 compatible. Can we get another kokoro run, @anandolee?

Copy link
Contributor

@anandolee anandolee left a comment

Choose a reason for hiding this comment

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

@jskeet , are you able to help review this PR? This change added extension and will Obsolete custom options. I'd like to make sure the basic APIs looks good to you before we enable proto2 generator as you are the major contributor.

Note: tests are not added because we haven't enable proto2 generator yet. All proto2 support PRs (including #4642 #5183 and this one) did not affect users yet and we could make API change. Related tests will be added in the final proto2 support PR which enables proto2 generator.

@jskeet
Copy link
Contributor

jskeet commented Dec 17, 2018

I'm afraid I wouldn't have time to look at this until mid January at the earliest

Copy link
Contributor Author

@ObsidianMinor ObsidianMinor left a comment

Choose a reason for hiding this comment

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

API changes will happen next PR, @anandolee, as they require public descriptor protos.

@anandolee
Copy link
Contributor

anandolee commented Dec 18, 2018

@jskeet
Understand. Most people will be OOO for next two weeks. I will review this PR. Can you help review the next (final) PR? The next PR will enable proto2 generator, change the descriptor protos public, enable all the APIs Sydney has added and will add all the tests. I assume it will be late January or February

@jskeet
Copy link
Contributor

jskeet commented Dec 18, 2018

I'll see when the time comes, but hopefully I'll be able to help. It'll have to be somewhat time limited though.

@lostindark
Copy link

This seems has been opened for quite some time. Any updates?
I'm eager to test proto2 support.

@ObsidianMinor
Copy link
Contributor Author

I believe we're still waiting for @anandolee to review @lostindark

csharp/src/Google.Protobuf/ExtensionSet.cs Outdated Show resolved Hide resolved
csharp/src/Google.Protobuf/ExtensionSet.cs Outdated Show resolved Hide resolved
csharp/src/Google.Protobuf/ExtensionSet.cs Outdated Show resolved Hide resolved
@ObsidianMinor ObsidianMinor force-pushed the csharp/proto2-feature/extensions branch from 2e6d38c to b72a3ff Compare May 2, 2019 18:50
@ObsidianMinor
Copy link
Contributor Author

I think you also need to add a "release notes: no" label to pass Mergable's checks @anandolee

@anandolee anandolee merged commit 9e89b6e into protocolbuffers:master May 3, 2019
Copy link
Contributor

@jtattermusch jtattermusch left a comment

Choose a reason for hiding this comment

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

A few additional nits that would be good to address in #5936

csharp/src/Google.Protobuf/FieldCodec.cs Show resolved Hide resolved
{
return new FieldCodec<T>(input => { T message = parser.CreateTemplate(); input.ReadMessage(message); return message; },
(output, value) => output.WriteMessage(value), message => CodedOutputStream.ComputeMessageSize(message), tag);
(output, value) => output.WriteMessage(value), (CodedInputStream i, ref T v) =>
Copy link
Contributor

Choose a reason for hiding this comment

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

I feel like this method is not very readable (also below)

Copy link
Contributor

@jtattermusch jtattermusch left a comment

Choose a reason for hiding this comment

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

Some more comments.
The changes have only been released as part of 3.9.0, which is currently unlisted on nuget, so I think the comments should be addressed in v3.9.1 if the extensions API is exposed in the public API in any useful way (or is the API completely useless right now and it's going to be only start being usable with #5936?)
I'm still reviewing the Extension, ExtensionSet, ExtensionValue, ... APIs to make sure they are making sense. What is the best place to look at to see the intended usage of extensions in C#?

CC @anandolee

csharp/src/Google.Protobuf/ExtensionSet.cs Show resolved Hide resolved
csharp/src/Google.Protobuf/Extension.cs Show resolved Hide resolved
csharp/src/Google.Protobuf/Extension.cs Show resolved Hide resolved
@ObsidianMinor
Copy link
Contributor Author

(or is the API completely useless right now and it's going to be only start being usable with #5936?)

Correct, you can't generate any code that uses Extension or ExtensionSet with this PR.

I'm still reviewing the Extension, ExtensionSet, ExtensionValue, ... APIs to make sure they are making sense. What is the best place to look at to see the intended usage of extensions in C#?

There's many tests you can browse to see how to use extensions (ExtensionSet and ExtensionValue are not exposed).

IExtensionValue value;
if (first.ValuesByNumber.TryGetValue(pair.Key, out value))
{
value.MergeFrom(pair.Value);
Copy link
Contributor

Choose a reason for hiding this comment

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

if the extension value happens to be of the wrong kind (ExtensionValue vs RepeatedExtensionValue), extensionValue.MergeFrom(stream) silently ignores the value (there's a "is" check). Is that intended?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, is that not the correct behavior for merging?

Copy link
Contributor

Choose a reason for hiding this comment

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

not sure. @anandolee would know better?

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

Successfully merging this pull request may close these issues.

None yet

9 participants