- From: Andrei Popescu <andreip@google.com>
- Date: Fri, 27 Jun 2008 19:59:09 +0100
- To: "Shyam Habarakada" <shyamh@microsoft.com>
- Cc: "public-geolocation@w3.org" <public-geolocation@w3.org>, "Alec Berntson" <alecb@windows.microsoft.com>
Hi Shyam, On Thu, Jun 26, 2008 at 10:11 PM, Shyam Habarakada <shyamh@microsoft.com> wrote: > Andrei, > I just noticed that you had moved the errorCallback (as well as another reference to the successCallback) into PositionOptions. This seems like a strange API design to me, but I can see why you may have gone this route (I did not see a detail discussion on the WG that lead to this approach). Given the way argument passing and function overloading works in javascript, it is tricky to do something like getPosition(successCallback [, errorCallback] [, positionOptions]) as I originally suggested to the WG. > > A cleaner approach might be to revert to a single callback approach and modify the signature of the callback so that Position and Error/Status data is decoupled. > > Say, > > interface PositionCallback { > void handleEvent(in PositionStatus status, in Position position); > }; > > Where, > > interface PositionStatus { > readonly int code; > readonly DOMString message; > }; > > > Thoughts? > I think this is certainly a good idea. The implication, however, is that 100% of the code using this API would look as follows: if (!status.code) { callSuccessHanlder(); } else { callErrorHandler(status.code); } How would you feel about leaving the errorCallback as a property of the PositionOptions interface and having the successCallback always be the first parameter? Many thanks, Andrei
Received on Friday, 27 June 2008 18:59:52 UTC