- From: Andrei Popescu <andreip@google.com>
- Date: Wed, 7 Apr 2010 19:10:41 +0100
- To: Robin Berjon <robin@robineko.com>
- Cc: public-geolocation@w3.org, public-device-apis@w3.org
Hi Robin,
On Wed, Apr 7, 2010 at 3:58 PM, Robin Berjon <robin@robineko.com> wrote:
> Dear Geo WG,
>
> I am writing to you on behalf of the DAP WG. We have been discussing various styles of parameter passing for our APIs, and there is a tendency to lean towards the object literal style. However we noted while discussing this that that isn't the approach you had taken. This mostly concerns API calls that involve callbacks (of which we have many).
>
> To provide examples, you have APIs set up like this:
>
> navigator.geolocation.getCurrentPosition(successCB, errCB, { option: "foo", option2: "bar"});
>
> Since the error callback is optional, but options are useful, this leads to things like:
>
> navigator.geolocation.getCurrentPosition(successCB, null, { option: "dahut" });
>
> We were thinking about going to full object literal:
>
> navigator.device.doSomethingCool({ success: scb, error: ecb, dahut: true, unicorn: false });
>
> Our question isn't "what do you prefer?" as we'd like to avoid a cross-list discussion about who likes which style best but rather "did you discuss these differences, and if so what motivated your choice and can we please have a pointer to that >discussion?"
>
Yes, this was one of the first things we discussed:
http://www.w3.org/2008/geolocation/track/issues/20
Since in most cases we felt that developers would simply want
getCurrentPosition(successCallback, errorCallback), we felt it's nicer
to have two separate callbacks rather than force everyone to create a
wrapper object and mandate that the wrapper must have a property
called 'success'. Not sure how this applies to your APIs, though.
Thanks,
Andrei
Received on Wednesday, 7 April 2010 18:11:11 UTC