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

[generator] Change protected members in sealed classes to private. #569

Merged
merged 1 commit into from
Feb 11, 2020

Conversation

jpobst
Copy link
Contributor

@jpobst jpobst commented Feb 11, 2020

When generating API-29 Mono.Android.dll we get ~12 warnings that we are declaring a new protected member in a sealed class:

warning CS0628: 'HttpHost.Hostname': new protected member declared in sealed class

The C# compiler makes these members private anyways, so we can change generator to make them private to eliminate the warning without being a breaking change. The value in continuing to bind them as private as opposed to removing them is that they could be used by custom code in partial classes.

@jpobst jpobst requested a review from jonpryor February 11, 2020 19:45
@jpobst jpobst changed the title [generator] Change protected members in sealed class to private. [generator] Change protected members in sealed classes to private. Feb 11, 2020
@jonpryor jonpryor merged commit 47201c4 into master Feb 11, 2020
@jonpryor jonpryor deleted the sealed-protected branch February 11, 2020 20:53
jonpryor pushed a commit that referenced this pull request Feb 19, 2020
When generating `Mono.Android.dll` for API-29/v10.0, we get ~12
warnings that we are declaring a new `protected` member within a
`sealed` class, e.g.:

	warning CS0628: 'HttpHost.Hostname': new protected member declared in sealed class

There are (at least) three plausible ways to address this warning:

 1. Use `Metadata` to change the visibility of these members.
 2. Update `generator` so that it doesn't emit the members at all.
 3. Update `generator` so the visibility of the members is `private`.

The problem with (1) is that if the Java type ever changes in the
future to be *non*-`final` -- meaning `protected` members would
"make sense" -- the members will remain changed, and will continue
until some manual review occurs, which is unlikely to happen.

(2) is appealing -- no members at all means smaller bindings -- but
means that the members cannot be used from additional `partial` class
declarations.

(3) allows the members to be used from `partial` classes, if desired,
while ensuring that if the type changes to become non-`final` in the
future, visibility will "automatically" remain `protected`.

Update `generator` so that `protected` members within `final` types
are instead bound as `private` members, thus avoiding the CS0628.
@github-actions github-actions bot locked and limited conversation to collaborators Apr 13, 2024
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.

3 participants