Michael Fawcett wrote:
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; }
Nope. Your dialog manager would keep track of the unit and set appropriately upon initialization and/or user interaction. Your reader would then be as simple as setting the value directly to the quantity. Alternatively you might have something like this: quantity<abstract> on_dialog_ok() { quantity<abstract> dist; dist.set_unit(combo.selected_item().data()); dist.set_value(entry.value().as_double()); } No more switch statement smell.