From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a24:7d0b:: with SMTP id b11-v6mr1593014itc.30.1533835964196; Thu, 09 Aug 2018 10:32:44 -0700 (PDT) X-Received: by 2002:aca:75c9:: with SMTP id q192-v6mr107573oic.3.1533835963993; Thu, 09 Aug 2018 10:32:43 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.linkpendium.com!news.linkpendium.com!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!g13-v6no3054960itf.0!news-out.google.com!k71-v6ni4012itk.0!nntp.google.com!g13-v6no3054958itf.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 9 Aug 2018 10:32:43 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.195.62; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.195.62 References: <9381f30a-a957-4477-b037-b2d60041e83e@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <60ddd5ae-57e1-45e8-929c-302fabaa24ef@googlegroups.com> Subject: Re: SI Units Checked and Unchecked From: "Dan'l Miller" Injection-Date: Thu, 09 Aug 2018 17:32:44 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:54113 Date: 2018-08-09T10:32:43-07:00 List-Id: 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: >=20 > > So, Dmitry, you are making the mistake of excessive reuse in the app-do= main of an unfinished library.=20 > > Sure, at some deep level in the library, there can be a bland gauge tha= t 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 li= brary, 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 y= ou speak. >=20 > No, I am speaking about a widget that checks and enforces measurement=20 > units. as am I > If you look how GUI widgets are constructed you would notice=20 > adjustment objects, which should utilize the compile-time-enforced strongly-typed types, not un= itless scalars > events to propagate, which should utilize the compile-time-enforced strongly-typed types, not un= itless scalars > properties to set and query,=20 which should utilize the compile-time-enforced strongly-typed types, not un= itless scalars > MVC which should utilize the compile-time-enforced strongly-typed types, not un= itless scalars > and dozens of other things which should utilize the compile-time-enforced strongly-typed types, not un= itless scalars > connecting the widget to the world around=20 > it, all dealing with measurement units. There is no way anybody could=20 > design this with generics or statically typed. So you can't use /this/ name instead of /that/ name of type. Gee, your key= board is so weird that it won't let you type /this/ strongly-typed identifi= er instead of /that/ weakly-typed identifier in app-domain declarations of = instantiations. > It can be statically constrained though, in some few cases, because=20 > widgets are customary stored and restored. There might be some limited=20 > cases with all static layouts in avionics or medical applications, these= =20 > are an exception from the common rule. Safety-critical uses a different set of rules than =E2=80=9Cthe common rule= =E2=80=9D of which you speak. > And note that speed and pressure are measured in dozens different units.= =20 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= =20 > allowed. E.g. an adjustment object in kPa should work with a barograph=20 > indicating mm Hg. where =E2=80=9Cworks with=E2=80=9D is defined as having an overtly-instanti= ated converter object between them, where the converter object again assure= s 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 declar= e a few more conversions than supplied by the less-insightful library desig= ner (e.g., even avoirdupois to metric and vice versa, Queen Anne 1707 syste= m still in wide use in the USA to metric and vice versa, King George III 1= 824 system in former use throughout the British Empire to metric and vice v= ersa. Just like the rule of not hardcoding a single iterator/cursor into a contai= ner, don't hardcode conversions or prohibitive lack thereof into the compil= e-time-enforced strong-typing units-of-measure dimension types. > And I don't remember a single customer who ever wanted=20 > 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 th= at the customer speaks the language of the customer, not of some library de= signer (who sought effort reduction). The purpose of engineering is to ser= ve the customer's expectations, not to the library designer's whim.