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

Belatedly, here's a PR to change the interfaces-and-constants that were the
subject of this thread, to static methods on an interface that take
strings: https://github.com/WebBluetoothCG/web-bluetooth/pull/112. Please
let me know if that PR is a direction public-script-coord likes.

Thanks,
Jeffrey

On Tue, Sep 30, 2014 at 4:11 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Tue, Sep 30, 2014 at 3:40 AM, Jeffrey Yasskin <jyasskin@google.com>
> wrote:
> > Does your advice also mean that the bluetooth system as a whole should
> > be a class too, instead of a navigator.bluetooth that comes out of
> > nowhere? But what would it mean to write `new BluetoothAdapter()`? You
> > can't construct a new Bluetooth radio in software. You could imagine
> > having it ask the browser to emulate a new device, but most existing
> > hardware can't even emulate a new device for each origin, let alone
> > multiple devices for each origin.
>
> Yeah I'm not sure. I guess my general advice might not be applicable
> here.
> http://lists.w3.org/Archives/Public/public-script-coord/2014JulSep/thread.html#msg213
> has a discussion on sensor APIs. Perhaps some of those ideas are
> applicable to Bluetooth.
>
>
> > I don't understand what that means. We have some root object, either:
> > 1) root_object = AClass;
> > 2) root_object = navigator.foo;
> > 3) root_object = new AClass();
> > and then that object can expose constants as either attributes or as
> > the result of methods: root_object.a_constant or
> > root_object.get('a_constant').
> >
> > https://www.khronos.org/registry/webgl/specs/1.0/#WebGLRenderingContext
> > does this as attributes (although with the discouraged WebIDL const
> > keyword), while Marcos is suggesting we imitate Map's methods.
>
> For constants the platform typically uses strings these days. See e.g.
> XMLHttpRequest's responseType or JavaScript's
> String.prototype.normalize().
>
>
> --
> https://annevankesteren.nl/
>