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 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: SI Units Checked and Unchecked Date: Thu, 9 Aug 2018 21:42:45 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <9381f30a-a957-4477-b037-b2d60041e83e@googlegroups.com> <60ddd5ae-57e1-45e8-929c-302fabaa24ef@googlegroups.com> NNTP-Posting-Host: IzvqdhUtDGKIMCldyDtZ+w.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.8.3 Xref: reader02.eternal-september.org comp.lang.ada:54117 Date: 2018-08-09T21:42:45+02:00 List-Id: On 2018-08-09 19:32, Dan'l Miller wrote: > 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 The scalars are not unitless. The unit is a discriminant: http://www.dmitry-kazakov.de/ada/units.htm The point is that like in the design proposed by Christoph the constraint is not static. [...] >> 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. There is no usable design based on unrelated types [*]. There must exist dimensioned objects capable to hold values of different units. Similarly to class-wide objects this by no means constitutes weak typing. >> 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. No converter objects needed. Operations are defined directly on the dimensioned values. You can add 5 m/s to 10 km/h, the result is always physically correct. This design has its drawbacks, e.g. it would prevent use of fixed-point types, because you would lose control over precision. > 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. As I said there no hard-coded conversions whatsoever. >> 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? Right. That is why the measurement unit of a widget cannot be a part of its type and why the widgets cannot deploy a fixed system of units. > 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. That is one of the requirements, which BTW precludes type-based solutions. All production code used in automation systems is based on subtypes. ---------------------- * Note that dimensioned types could build a class. Then they would be related and there would be class-wide objects to hold values of any dimension. This sort of design is thinkable, but it would possibly require even deeper changes of the Ada type system than a design based on subtypes/constraints. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de