Length Per Angle Unit (e.g. mm/rev, m/degree)

[CalebBe-2253]

Is your feature request related to a problem? Please describe.
I need to represent the ratio between a length and an angle in my project. As far as I am aware there is no way to represent this in UnitsNet.

This quantity is used frequently in the manufacturing industry, and is often used to represent the depth drilled per revolution of a cutter. It can also be used to represent arc lengths, which is generally useful in many forms of mathematics.

Describe the solution you'd like
I would like a new quantity type "LengthPerAngle".
A reasonable minimum set of units would be something like the following, but of course more units are possible:

1. MillimeterPerDegree
2. MillimeterPerGradian
3. MillimeterPerRadian
4. MillimeterPerRevolution
5. CentimeterPerDegree
6. CentimeterPerGradian
7. CentimeterPerRadian
8. CentimeterPerRevolution
9. MeterPerDegree
10. MeterPerGradian
11. MeterPerRadian
12. MeterPerRevolution
13. InchPerDegree
14. InchPerGradian
15. InchPerRadian
16. InchPerRevolution
17. FootPerDegree
18. FootPerGradian
19. FootPerRadian
20. FootPerRevolution
21. YardPerDegree
22. YardPerGradian
23. YardPerRadian
24. YardPerRevolution

Describe alternatives you've considered
As far as I am aware, the only alternative is to manage the units and conversions manually.

[tmilnthorp]

Given the frequency of requests for UnitPerUnit requests, I believe an operand struct of sorts would help us be more flexible overall. Just not sure of the desire to implement, and I know we’ve debated similar things in the past. Just returning a bit after some absence so forgive me. @angularsen?

[angularsen]

Hi, yes I think I agree. There are just too many X-per-Y units out there to add them all, and I kind of think this falls in the bucket of too domain specific, sorry. UnitsNet is all about static typing, and we currently don't have a good way to accommodate everyone.

I updated the wiki with a note on X-per-Y units:
https://github.com/angularsen/UnitsNet/wiki/Adding-a-New-Unit#great--but-before-you-start-

Some options we have discussed:

1. Source generators: XP: Prototype source generator #1500
2. Split up into a core nuget and individual nugets, like we do for .NET nanoFramework

Some options you can consider:

1. Code the units yourself
2. Optionally add it as a custom unit in UnitsNet, primarily to reuse parsing and unit conversion.

P.S: Welcome back @tmilnthorp! 😃

[lipchev]

@tmilnthorp Welcome back! FYI I've been doing a lot of work in the direction of working-with-custom-quantities (well, that's just a small part of it really). I was waiting for @angularsen to catch up with the reviews, but my internal build seems to have everything working nicely. I am going to publish two versions (one using a transient dependency on the Fractions library, and the other one, with everything implemented internally).

Anyways, one PR that you would probably find interesting is #1507 - I'm relying heavily on the UnitKey concept, both for the UnitAbbreviations and the UnitConverter (which you'd be happy to see, now also includes options for caching every Unit->Unit conversion as in #1227). It also clears up all of the switch statements, and allows us to register custom conversions quite easily (in fact it's mostly automatic).

[CalebBe-2253]

@angularsen Thanks for the comment. I've been reading through the custom units page and the sample quantity does not conform to the up-to-date IQuantity interface.

1. QuantityType no longer exists,
2. QuantityInfo has had some breaking changes, relating to QuantityType and UnitInfo,
3. QuantityValue Value { get; } had replaced double Value { get; },
4. and bool Equals(IQuantity? other, IQuantity tolerance); has been added to the interface.

[angularsen]

@CalebBe-2253 Thanks for pointing it out, there are many changes to IQuantity in release/v6 as well so the wiki will need an update to match that too. Some notes here #1200 .