Re: SI Units Checked and Unchecked

["Dan'l Miller" <optikos@verizon.net>]

On Thursday, August 9, 2018 at 10:51:59 AM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-08-09 17:03, Dan'l Miller wrote:
> 
> > So, Dmitry, you are making the mistake of excessive reuse in the app-domain of an unfinished library. 
> > Sure, at some deep level in the library, there can be a bland gauge that skeuomorphically represents a > > swinging black needle on a white circle that has no idea whether it is measuring pressure or amperes
> > or volts or speed.  But at the intended user-interface facade of the library, there should be:
> > 1) a strongly-typed gauge for amperes,
> > 2) a separate strongly-typed gauge for pressure,
> > 3) a separate strongly-typed gauge for volts,
> > 4) a separate strongly-typed gauge for speed,
> > and so forth that are wrappers around the one shared white circle with swinging black needle as the
> > bland unitless-clueless(-at-engineering-/compile-time) gauge of which you speak.
> 
> No, I am speaking about a widget that checks and enforces measurement 
> units.

as am I

> If you look how GUI widgets are constructed you would notice 
> adjustment objects,

which should utilize the compile-time-enforced strongly-typed types, not unitless scalars

> events to propagate,

which should utilize the compile-time-enforced strongly-typed types, not unitless scalars

> properties to set and query, 

which should utilize the compile-time-enforced strongly-typed types, not unitless scalars

> MVC

which should utilize the compile-time-enforced strongly-typed types, not unitless scalars

> and dozens of other things

which should utilize the compile-time-enforced strongly-typed types, not unitless scalars

> connecting the widget to the world around 
> it, all dealing with measurement units. There is no way anybody could 
> design this with generics or statically typed.

So you can't use /this/ name instead of /that/ name of type.  Gee, your keyboard is so weird that it won't let you type /this/ strongly-typed identifier instead of /that/ weakly-typed identifier in app-domain declarations of instantiations.

> It can be statically constrained though, in some few cases, because 
> widgets are customary stored and restored. There might be some limited 
> cases with all static layouts in avionics or medical applications, these 
> are an exception from the common rule.

Safety-critical uses a different set of rules than “the common rule” of which you speak.

> And note that speed and pressure are measured in dozens different units. 

and they should all be supported, even ones that are out-of-vogue, such as CGS instead of MKS, and SI prefixes thereof

> One of the requirements of sane design is that all compatible units were 
> allowed. E.g. an adjustment object in kPa should work with a barograph 
> indicating mm Hg.

where “works with” is defined as having an overtly-instantiated converter object between them, where the converter object again assures compile-time physics-correct enforcement of strongly-typed input units of measure to strongly-typed output units of measure.  Indeed, in addition to providing all the customary conversions (e.g., MKS to CGS and vice versa), the library must provide a toolkit for the app-domain programmer to declare a few more conversions than supplied by the less-insightful library designer (e.g., even avoirdupois to metric and vice versa, Queen Anne 1707 system still in wide use in the USA to metric and vice versa,  King George III 1824 system in former use throughout the British Empire to metric and vice versa.

Just like the rule of not hardcoding a single iterator/cursor into a container, don't hardcode conversions or prohibitive lack thereof into the compile-time-enforced strong-typing units-of-measure dimension types.

> And I don't remember a single customer who ever wanted 
> his HMI showing speed in SI's m/s.

Why in the world would a GUI widget library dictate the requirements to the customer, as a tail wagging the dog?  The strongly-type GUI widget library should present a physics-correct plethora of options to the customer so that the customer speaks the language of the customer, not of some library designer (who sought effort reduction).  The purpose of engineering is to serve the customer's expectations, not to the library designer's whim.