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

Change 'static readonly' fields to 'const', where appropriate #662

Open
NightOwl888 opened this issue Oct 15, 2022 · 1 comment
Open

Change 'static readonly' fields to 'const', where appropriate #662

NightOwl888 opened this issue Oct 15, 2022 · 1 comment
Assignees
Labels
good-first-issue Good for newcomers hacktoberfest-accepted is:enhancement New feature or request pri:normal up-for-grabs This issue is open to be worked on by anyone

Comments

@NightOwl888
Copy link
Contributor

For private fields that are either primitive type or string, we can simply change these to const with no ill effects (which can be its own PR).

For internal/public/protected fields, generally the answer is yes, we should change these. However, changing to const means compiling the value into a consuming assemblies' metadata, so we need to be judicious on how to deal with these.

  1. If the value will certainly never change, we can change to const.
  2. If the value is likely to change, we should leave as static readonly.
  3. All other cases need to be considered carefully.

For example, we need to consider the implications of what will happen if someone uses an older version of one of the modules, such as Lucene.Net.Analysis.Common with a newer version of Lucene.Net that has updates to these constant values. If there is any doubt, these should be static readonly.

Do note that making this change may result in compile errors which means we need to either revert the change or apply a fix, if appropriate.

NOTE: In Java, there is only one option, static final, so this is a .NET-specific translation problem and there is no need to add a // LUCENENET comment for it.

@NightOwl888 NightOwl888 added up-for-grabs This issue is open to be worked on by anyone good-first-issue Good for newcomers is:enhancement New feature or request hacktoberfest-accepted labels Oct 15, 2022
@paulirwin paulirwin added this to the 4.8.0 milestone Oct 28, 2024
@paulirwin paulirwin modified the milestones: 4.8.0, 4.8.0-beta00018 Nov 11, 2024
@paulirwin paulirwin self-assigned this Nov 11, 2024
@paulirwin
Copy link
Contributor

Bumping this to beta 18 in light of #1014 feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good-first-issue Good for newcomers hacktoberfest-accepted is:enhancement New feature or request pri:normal up-for-grabs This issue is open to be worked on by anyone
Projects
None yet
Development

No branches or pull requests

2 participants