W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2014

Re: Advice on how to best handle a long list of attributes

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 25 Sep 2014 16:55:45 -0700
Message-ID: <CAAWBYDAJTYjSThzF9t+sWxXWTgWQzp9_Cwozd1gC0EOsfcxTVg@mail.gmail.com>
To: Marcos Caceres <marcos@marcosc.com>
Cc: public-script-coord <public-script-coord@w3.org>, Jeffrey Yasskin <jyasskin@google.com>
On Thu, Sep 25, 2014 at 4:09 PM, Marcos Caceres <marcos@marcosc.com> wrote:
> The Web BlueTooth API currently specifies interfaces that serve as lookup tables for values [1], which can lead to code that looks like this (extreme example):
> ```
> //returns a UUID string
> navigator.bluetooth.uuids.catalytic_activity_concentration.katal_per_cubic_metre
> ```
> Clearly, that's not ideal to type out. I'm wondering if anyone has some recommendations of how we can clean this up a bit. We've thrown around some ideas [2], like using a WebIDL [MapClass] to look up values using enums:
> ```
> BluetoothUnitMap.get("katal_per_cubic_metre");
> ```
> or exposing things like the above as static constants on interface objects:
> ```
> BluetoothUnitMap.catalytic_activity_concentration.katal_per_cubic_metre
> ```
> ... but nothing feels quite right :/
> Can anyone think of a better way of approaching this problem? Maybe it doesn't matter?
> [1] https://webbluetoothcg.github.io/web-bluetooth/#standard-gatt-units
> [2] https://github.com/WebBluetoothCG/web-bluetooth/issues/49

Looking through the list, these are the only entries with duplicate leaf names:

* surface_charge_density.coulomb_per_square_metre

* density.kilogram_per_cubic_metre

* time.minute

* time.second

* heat_flux_density.watt_per_square_metre

The minute/second ones can just be renamed to use arcminute and
arcsecond or something.  The other three pairs appear to be identical
units; the "density" and "irradiance" pairs even appear to be
identical uses!  (The electric one might be too, but I don't feel like
looking up those terms to see how comparable they are.)

So yes, just producing a flat unit map seems just fine, with the
time/angle collision sorted out.

(It looks like these are all from an existing standard, so it wouldn't
be worthwhile to try and produce a more robust system of units,

Received on Thursday, 25 September 2014 23:56:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:22 UTC