-
Notifications
You must be signed in to change notification settings - Fork 396
QuantityInfo
: internalizing the UnitInfo
construction
#1555
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
QuantityInfo
: internalizing the UnitInfo
construction
#1555
Conversation
- QuantityInfo: introducing a delegate for constructing the quantity (required only for net standard) - QuantityInfo: introducing an optional ResourceDictionary - UnitInfo: introducing a back-reference to the QuantityInfo (making the QuantityName [Obsolete]) - IQuantity: added the QuantityInfo<TQuantity, TUnit>, the From(double, TUnit) method and default implementations for the non-generic properties - UnitAbbreviationsCache: ReadAbbreviationsFromResourceFile implemented using the provided ResourceDictionary (if available) - updating the QuantityInfo definitions for all quantities (introducing a concrete class, such as MassInfo) with helpers for creating a derried configuration - HowMuch upgraded to IQuantity<HowMuch, HowMuchUnit> (the original QuantityInfo is now abstract) - UnitsNet.csproj / UnitsNet.Tests.csproj: added some (specific) implicit usings
…e methods for dynamically adding a UnitInfo
QuantityInfo
: internalizing the UnitInfo
construction (WIP)QuantityInfo
: internalizing the UnitInfo
construction
@angularsen The most breaking thing here should be the change from Providing a delegate and resource dictionary in the PS The PS2 The new size is:
which is up from
but that would go down again, when I remove all the
|
UnitsNet.Benchmark/Initializations/UnitAbbreviationsCacheInitializationBenchmarks.cs
Outdated
Show resolved
Hide resolved
UnitsNet.Benchmark/Initializations/QuantityInfoInitializationBenchmarks.cs
Outdated
Show resolved
Hide resolved
/// <summary> | ||
/// Creates a new instance of the <see cref="MassInfo"/> class with the default settings for the Mass quantity and a callback for customizing the default unit mappings. | ||
/// </summary> | ||
/// <param name="customizeUnits"> | ||
/// A callback function for customizing the default unit mappings. | ||
/// </param> | ||
/// <returns> | ||
/// A new instance of the <see cref="MassInfo"/> class with the default settings. | ||
/// </returns> | ||
public static MassInfo CreateDefault(Func<IEnumerable<UnitDefinition<MassUnit>>, IEnumerable<IUnitDefinition<MassUnit>>> customizeUnits) | ||
{ | ||
return new MassInfo(nameof(Mass), DefaultBaseUnit, customizeUnits(GetDefaultMappings()), new Mass(0, DefaultBaseUnit), DefaultBaseDimensions); | ||
} |
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.
Ah, you might be wondering about this thing here (currently uncovered by tests). It allows us to include, exclude or re-configure certain units (not very useful In the current version, where the conversion expressions are still not available).
Here's how this is covered in #1544 : MassTestsBase.g.cs.
The problem is that this it uses these extensions, (tested here) which, I just realized, are using two generic type parameters, making them susceptible to the bug with ReSharper.
If you think we can Ignore and Continue (and you agree with the rest of the changes so far), then I can add them here.
PS Note that in #1544 I went to even further and (with the use of some dazzling re-directions) was able to make the default Mass.Info
configurable from the UnitsNetSetup.DefaultConfigurationBuilder
, but that's still ahead of us (should you decide to take the red pill 🤣 ).
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.
FYI - the re-sharper bug was actually closed (as fixed in the EAP version)- I'm expecting the official version to come out next week or so (according to a post I saw 2 weeks ago).
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.
ReSharper bug is apparently fixed in 2025.2 EAP 5, 2025.2 EAP 6
@lipchev just a heads up that this week is crazy for me and I'm traveling this weekend, not sure I'll get around to much |
This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days. |
This PR was automatically closed due to inactivity. |
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.
Very nice, I like the overall direction. Mostly minor comments and suggestions that can be addressed later, I tried pushing fixes but don't have permission to push to your fork. Will push a few commits after merging this PR.
/// <summary> | ||
/// Provides detailed information about the <see cref="Acceleration"/> quantity, including its name, base unit, unit mappings, base dimensions, and conversion functions. | ||
/// </summary> | ||
public sealed class AccelerationInfo: QuantityInfo<Acceleration, AccelerationUnit> | ||
{ |
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.
I'm a little on the fence on the usefulness of having a concrete class for each quantity's info, and we have 100+ quantities that will add to the binary size.
If it's about syntax, a type alias would achieve much the same.
I don't expect to pass AccelerationInfo
around or something consumers of UnitsNet should think about.
For extensibility, it doesn't seem to offer much.
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.
I gave it a go to refactor to private static factories, with minimal diff. Please take a look.
#1580
I think unless we actually need the concrete type for quantity info, let's just reuse the generics we already have to reduce generated code.
QuantityInfo
: internalizing theUnitInfo
constructionQuantityInfo
: introducing a delegate for constructing the quantity (required only for net standard)QuantityInfo
: introducing an optionalResourceDictionary
QuantityInfo
: replacing theTUnit[]
with anIReadOnlyCollection<TUnit>
UnitInfo
: introducing a back-reference to theQuantityInfo
(making theQuantityName
[Obsolete]
)IQuantity
: added theQuantityInfo<TQuantity, TUnit>
, theFrom(double, TUnit)
method and default implementations for the non-generic propertiesQuantityInfoLookup
: added another collection for the quantity by type mapping (replacing the generated code inQuantity.g.s
).UnitAbbreviationsCache
:ReadAbbreviationsFromResourceFile
implemented using the providedResourceManager
(if available)QuantityInfo
definitions for all quantities (introducing a concrete class, such asMassInfo
) with helpers for creating a derived configurationHowMuch
upgraded toIQuantity<HowMuch, HowMuchUnit>
(the originalQuantityInfo
is now abstract)Quantity
refactored theParse
/From*
methods using the defaultQuantityParser
/QuantityInfoLookup
Quantity
replaced theByName
dictionary with anIReadOnlyDictionary
UnitsNet.csproj
/UnitsNet.Tests.csproj
: added some (specific) implicit usings