You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As discussed in #858 and #864, I'd like to open a tracking issue for various extensibility features. I propose enumerating the different use cases and then prioritize per use case the feasibility and desirability of supporting and implementing them. I'll be available to assist in implementation too (limited).
Use cases
Below follow use cases. Please mention your own in the discussion and describe them clearly. I will update this top post to include yours. For convenience and reference, I have included a technical name behind the title.
If some of these usecases are already supported, I will remove them.
Derived quantities DerivedQuantities
While quantities can often be applied, it can often make more sense to have a different quantity of the same dimensions. Think of an application modelling geothermal pipes. Such application models the depth quantity of a pipe, not the length. Yet, both quantities share the same dimensions. Typically, the depth dimension only uses a subset of the length units. Lightyears and nanometers are simply not applicable, but meters and hectometers all the more. Also, as pipes come in prefabricated lengths, a unit to add here may be "pipe" equalling i.e. around 10m for one unit of measurement. Such unit should then be added to the specific depth quantity.
In short, depth is length with semantic difference and an inherited subset of units and added specific units.
Extra unit ExtraUnit
As DervicedQuantity example, but then the application can simply use an existing quantity but misses a unit. The user of UnitsNet should be able to easily specify that unit, generate some code, and then use it.
Extra quantity ExtraQuantity
As DervicedQuantity example, but then a completely new quantity with units. Think of an application that suddenly needs to use an esoteric unit of a quantity to do calculations.
Assume for a moment, like Russian culture has implementations in UnitsNet already, that new i18n of unit formatting/parsing is desirable. There should be an option to simply add these i18n customizations and use them.
Extra abbreviation within culture ExtraAbbreviation
Like ExtraCulture, but then a more specific abbreviation of a cultured unit. This happens often in specialized domains where the domain users have a different semantic pointer to an already existing unit. For example, I have seen instances of m/year in a domain where the more standard abbreviation is m/y.
Extra prefix ExtraPrefix
Add a new prefix to an existing unit.
Have UnitsNet api methods work with extended quantities/units ExtensibilityApi
While wandering around in the UnitsNet api, I have noted various instances of the api where assumptions were made that instances would only originate from the UnitsNets api itself. An example of this is the use of QuantityType: it's impossible to create a QuantityType by an external user, yet some api methods require a QuantityType value in order to work. Another example is the declaration of static lists. This works to get a list of default supported Quantities, but should not be mixed by the related but different "set of all used quantities" by a user (i.e. with included potentially added quantities).
A critical look should be directed to the various api methods and their implementations to explicitly take extended use cases into account.
CodeGen support CodegenSupport
The ability to have an api (such as Json or a builder C# api) to specify additions. From there, code can be generated and used primarily within the UnitsNet consumer code.
The text was updated successfully, but these errors were encountered:
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Overview
As discussed in #858 and #864, I'd like to open a tracking issue for various extensibility features. I propose enumerating the different use cases and then prioritize per use case the feasibility and desirability of supporting and implementing them. I'll be available to assist in implementation too (limited).
Use cases
Below follow use cases. Please mention your own in the discussion and describe them clearly. I will update this top post to include yours. For convenience and reference, I have included a technical name behind the title.
If some of these usecases are already supported, I will remove them.
Derived quantities
DerivedQuantities
While quantities can often be applied, it can often make more sense to have a different quantity of the same dimensions. Think of an application modelling geothermal pipes. Such application models the depth quantity of a pipe, not the length. Yet, both quantities share the same dimensions. Typically, the depth dimension only uses a subset of the length units. Lightyears and nanometers are simply not applicable, but meters and hectometers all the more. Also, as pipes come in prefabricated lengths, a unit to add here may be "pipe" equalling i.e. around 10m for one unit of measurement. Such unit should then be added to the specific depth quantity.
In short, depth is length with semantic difference and an inherited subset of units and added specific units.
Extra unit
ExtraUnit
As DervicedQuantity example, but then the application can simply use an existing quantity but misses a unit. The user of UnitsNet should be able to easily specify that unit, generate some code, and then use it.
Extra quantity
ExtraQuantity
As DervicedQuantity example, but then a completely new quantity with units. Think of an application that suddenly needs to use an esoteric unit of a quantity to do calculations.
Extra culture
ExtraCulture
Assume for a moment, like Russian culture has implementations in UnitsNet already, that new i18n of unit formatting/parsing is desirable. There should be an option to simply add these i18n customizations and use them.
Extra abbreviation within culture
ExtraAbbreviation
Like ExtraCulture, but then a more specific abbreviation of a cultured unit. This happens often in specialized domains where the domain users have a different semantic pointer to an already existing unit. For example, I have seen instances of
m/year
in a domain where the more standard abbreviation ism/y
.Extra prefix
ExtraPrefix
Add a new prefix to an existing unit.
Have UnitsNet api methods work with extended quantities/units
ExtensibilityApi
While wandering around in the UnitsNet api, I have noted various instances of the api where assumptions were made that instances would only originate from the UnitsNets api itself. An example of this is the use of QuantityType: it's impossible to create a QuantityType by an external user, yet some api methods require a QuantityType value in order to work. Another example is the declaration of static lists. This works to get a list of default supported Quantities, but should not be mixed by the related but different "set of all used quantities" by a user (i.e. with included potentially added quantities).
A critical look should be directed to the various api methods and their implementations to explicitly take extended use cases into account.
CodeGen support
CodegenSupport
The ability to have an api (such as Json or a builder C# api) to specify additions. From there, code can be generated and used primarily within the UnitsNet consumer code.
The text was updated successfully, but these errors were encountered: