Inherit same interfaces in wrapper types as generated types

[sequc82]

Wrapper types such as ReferencePressure are limited in polymorphism functionality. At this point, I'm not sure if there are any other wrapper types, the only other I am aware of is the idea of ReferenceVolumeFlow in #724. Since ReferencePressure does not inherit IQuantity et al., it does not behave as the generated types do. It can not be included in List<IQuantity> for example.

Extend the functionality of ReferencePressure to inherit the same implementation as all other IQuantity types.

For ReferencePressure, a potential workaround is to return Pressure as ReferencePressure.Absolute to use as an IQuantity, but that allows for mistakes to be made by users of the type as an IQuantity.

Essentially, extend ReferencePressure to:

public struct ReferencePressure : IQuantity<PressureUnit>, IEquatable<ReferencePressure>, IComparable, IComparable<ReferencePressure>, IConvertible, IFormattable

Aside from manually implementing all inherited functionality, has anything been done to simplify the resolution of this type of idea? I assume otherwise it would be rather straightforward.

[angularsen]

Hi,

Wrappers are a very new concept so we are still walking new ground here with ReferencePressure and ReferenceVolumeFlow in #724 .

I can't say I know either of these domains very well, but I have a hunch that we may run into problems trying to let these wrapper types implement IQuantity<TUnitEnum>.

The contract of this interface as of today is to represent a physical quantity. The main abilities of this contract is to be able to obtain the constructed value/unit pair, convert to other units of the same quantity and get the textual representation of the quantity.

In my experience, wrappers are useful to include extra information that is needed to bring context to the quantity beyond just a value and a unit, such as the pressure reference for the measured pressure or the temperature and fluid properties to represent the volume flow of a fluid. The type then provides methods to convert to other standard conditions like other pressure reference types or other temperatures for fluid volume flow.

I don't immediately see how this fits with IQuantity<>. For instance:

• QuantityInfo QuantityInfo {get;}: does a wrapper type really map to a physical quantity? I'm not so sure.
• double As(Enum unit);: How can ReferencePressure convert to PressureUnit.Pascal? As you mentioned, we could choose to return Absolute pressure property, but is that intuitive for everyone?

I'm truly asking, as I don't yet have enough understanding to have an opinion here yet.

But, to turn the question around, what are the benefits of implementing IQuantity<> for the wrapper types? Could it perhaps make sense to split up the rather big interface into smaller interfaces for Value+Unit, or for ToString() methods or some other subset of interface members that describe one facet of a physical quantity?

Best,
Andreas

[stale]

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.