On 3/26/07, Martin Schulz <Martin.Schulz@synopsys.com> wrote:
B) The presentation layer consists of everthing that is visible to the user, namely the GUI or the like. People in academics can hardly imagine what expectations engineers might have towards the units of their data. (Before entering industry, I was no exception to that rule :-) ) This is partly due to historical reasons; the choice of units in the presentation layer may vary by corporate guidelines, personal preference, professional background of the user or geographical location. If you want to get around with a single piece of code then, you cannot live with a fixed units for the quantities in your program. (The presentation layer, that is -- computation kernels are another story.)
I'm a little unclear on why some people think run-time support is required for robust interaction with GUIs. It could very well be a misunderstanding on my part, but with a user interface that allows arbitrary units, wouldn't you still need something like this: // Assume quantity<abstract> provides run-time support quantity<abstract> on_dialog_ok() { int selection = get_combobox_selection(ID_COMBO_DISTANCE); double value = get_editbox_value<double>(ID_EDIT_DISTANCE); quantity<abstract> distance; // This must be kept in sync with the dialog resource switch (selection) { case Meters: distance.reset(distance * meters); break; case Feet: distance.reset(distance * feet); break; // etc } return distance; } FWIW, the compile-time version of the above function looks very similar. You still have to have a case for each type, the only difference is that you have to decide during implementation what unit to convert everything to. Granted, the run-time version allows things like: // Note: conversion takes place behind the scenes here, // and you don't know which way the conversion happens. // Is this comparison done in meters or in feet? if (distance_in_meters > distance_in_feet) (Aside: Not that I have any understanding of the complexities involved, but wouldn't it be cool if the run-time component automatically chose the correct unit that would maximize precision? If it knew an overflow wouldn't happen, wouldn't doing the arithmetic at the largest level possible always be better? (e.g. feet + meters would be done in meters, feet + nanometers would be done in feet)
From my understanding, the run-time component allows mixed unit arithmetic. It allows for a nice syntax, but if one wants control over which way the conversion takes place, the user will still need to resort to being explicit (casts or constructors), at which point he has the same (or very similar) syntax as the compile-time version, except he's paying a run-time cost as well.
I'm not saying that a run-time version isn't needed, just that I don't understand the use cases yet, nor do I understand why a compile-time component isn't useful enough to be included in Boost as is.
As another example, consider simply a nifty small graph plotting widget. Clearly enough, this widget must handle whatever unit may arrive. Furthermore, users may decide to add or multiply some channels or combine them by some other means. Therefore the arithmetic operations for units are necessary at the runtime of the program.
Why wouldn't that widget use some base underlying unit and just convert all incoming values? --Michael Fawcett