New Units - 'Base pair' for quantity 'Length'

[rogerfydp]

Is your feature request related to a problem? Please describe.
Within existing quantity Length there is no units often used for "base pair (bp)"

Describe the solution you'd like
Base pairs (bp) is a unit of measurement for the length of nucleic acid sequences.

Will be nice to extend the quantity Length (if it's the proper one) to include base pairs (bp) such as shown in Wikipedia article, section Length measurements,

The following abbreviations are commonly used to describe the length of a D/RNA molecule:

bp = base pair—one bp corresponds to approximately 3.4 Å (340 pm) of length along the strand, and to roughly 618 or 643 daltons for DNA and RNA respectively.
kb (= kbp) = kilo–base-pair = 1,000 bp
Mb (= Mbp) = mega–base-pair = 1,000,000 bp
Gb (= Gbp) = giga–base-pair = 1,000,000,000 bp

Describe alternatives you've considered
None. Using other length units for 'Base pairs' is not common.

[angularsen]

Although I feel this is a bit too domain specific for the purpose of UnitsNet, I'm OK with adding it.

1. It only adds units to an existing quantity Length. Adding new quantities would set a higher bar for acceptance since it would add much extra generated code and binary size.
2. UnitsNet does not yet support any form of modularization, but it would scale better if consumers could bring in domain-specific units via separate nugets.

[lipchev]

By the way, with the upcoming C# 13 release there is a very useful addition:

https://devblogs.microsoft.com/dotnet/dotnet-build-2024-announcements/#extension-types

This would allow us to
a) have all Properties as extension methods (in a separate nuget if necessary)
b) give users the ability to extend existing quantities with a lot of the domain features that they are missing (well not the Enums but..)

[angularsen]

Super interesting @lipchev , first time I'm seeing this.
But do I understand correctly, that this is mostly syntax sugar?

a) have all Properties as extension methods (in a separate nuget if necessary)

This can be done today with extension methods instead of extension properties:
myLength.Meters() vs myLength.Meters

b) give users the ability to extend existing quantities with a lot of the domain features that they are missing

Similarly, if we accepted extension method syntax, we could achieve this today. Right?

[lipchev]

This can be done today with extension methods instead of extension properties: myLength.Meters() vs myLength.Meters

Today the user can add myLength.GetBasePairs() and in the future he should be able to have myLength.BasePairs.
There are also many other sugary stuff that become available. I saw a video about it some time ago- it was called The New Extensions EVERYTHING Feature of C# 13! 😄

I just hope that binding works out of the box, that would really be something (but I doubt it).
Also, this wont help us for .net472 and the #ifdefines we'd have to deal with sooner or later 😄 ..

[angularsen]

Bindings will probably not work, since the members are not part of the object you bind to.

[lipchev]

This can be done today with extension methods instead of extension properties: myLength.Meters() vs myLength.Meters

Today the user can add myLength.GetBasePairs() and in the future he should be able to have myLength.BasePairs. There are also many other sugary stuff that become available. I saw a video about it some time ago- it was called The New Extensions EVERYTHING Feature of C# 13! 😄

I just hope that binding works out of the box, that would really be something (but I doubt it). Also, this wont help us for .net472 and the #ifdefines we'd have to deal with sooner or later 😄 ..

Bad news- the feature is being postponed: Extension Types Are No Longer Coming in C# 13

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions]

This issue was automatically closed due to inactivity.