-
Notifications
You must be signed in to change notification settings - Fork 391
Replaced the IFormatProvider
parameter with CultureInfo
for all unit-related operations
#1542
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
Closed
+1,435
−1,405
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Why isn't this
IFormatProvider
also changed toCultureInfo
?double.Parse
can take aCultureInfo
, so why should we not just standardize onCultureInfo
here and other places?I tried reading up a bit on
IFormatProvider
, and its remarks section: https://learn.microsoft.com/en-us/dotnet/api/system.iformatprovider?view=net-9.0#remarksThe whole purpose of .NET standardizing on
IFormatProvider
, seems to me, is to support different custom formatters forstring.Format()
,ToString()
etc.There are 3 built in types: NumberFormatInfo, DateTimeFormatInfo and CultureInfo.
CultureInfo
holds both number formatting and date formatting, which makes this whole thing a bit weird:This is because
double.Parse()
callsNumberFormatInfo.GetInstance(provider)
to selectNumberFormatInfo
when given eitherCultureInfo
orNumberFormatInfo
, otherwise it falls back toCurrentCulture
.https://github.com/microsoft/referencesource/blob/master/mscorlib/system/double.cs#L235-L251
https://github.com/microsoft/referencesource/blob/master/mscorlib/system/globalization/numberformatinfo.cs#L285-L310
Long story short, I have a feeling it's maybe not a good idea for us to ditch
IFormatProvider
in our public methods, even if we do requireCultureInfo
in the end. Similar to how .NET's own types standardize onIFormatProvider
and has internal logic to obtain the compatible formatter, if any, or fallback toCurrentCulture
.To follow .NET conventions, I think we should just should do the same and cast internally, ignoring anything except
CultureInfo
for localization, and falling back toCurrentCulture
.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 reason why
IFormatProvider
is used inToString
andParse
is because they don't have any assumptions about whether theCultureInfo
orNumberFormat
(or theDateInfoFormat
) is required by the target type.On the other hand,
CultureInfo
is used for localizing strings (not sure if this is changing with theStringLocalizer
) where only the culture name is the key.In our case
Mass.Zero.ToString
should take anIFormatProvider
, passing it to theValue
(which uses the associatedNumberFormat
) and but type-casting it to aCultureInfo
when accessing theResourceDictionary
.Anyways, if you don't want to change it that's ok, I use nothing but
InvariantCulture
when dealing with the units.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.
That's my point,
double.Parse
indeed has an assumption on the formatter it wants, but it still supportsIFormatProvider
in order to accept bothNumberFormatInfo
andCultureInfo
. I guess several reasons, but consistency and also to make it easier for the developer to just pass whatever they have, instead of having to domyCulture.NumberFormat
every time.A similar point goes for us, since c# code typically passes
IFormatProvider
around, they'll have to start casting toCultureInfo
just to satisfy our public signature. I don't see much benefit to require a concrete type, but I see how it can cause annoying friction.Let's stay with
IFormatProvider
.