Skip to content

Support extensibility use cases #865

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
generateui opened this issue Dec 5, 2020 · 2 comments
Closed

Support extensibility use cases #865

generateui opened this issue Dec 5, 2020 · 2 comments

Comments

@generateui
Copy link
Contributor

generateui commented Dec 5, 2020

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 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.

@stale
Copy link

stale bot commented Mar 19, 2021

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.

@stale stale bot added the wontfix label Mar 19, 2021
@lipchev lipchev pinned this issue Apr 29, 2021
@stale stale bot removed the wontfix label Apr 29, 2021
@stale
Copy link

stale bot commented Jun 29, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant