- From: Andrei Popescu <andreip@google.com>
- Date: Thu, 22 Apr 2010 11:26:41 +0100
- To: Olli@pettay.fi
- Cc: Steve Block <steveblock@google.com>, public-geolocation <public-geolocation@w3.org>, dougt@dougt.org
On Thu, Apr 22, 2010 at 11:22 AM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote: > On 4/22/10 1:16 PM, Olli Pettay wrote: >> >> On 4/22/10 12:53 PM, Andrei Popescu wrote: >>> >>> On Thu, Apr 22, 2010 at 10:41 AM, Olli Pettay<Olli.Pettay@helsinki.fi> >>> wrote: >>>> >>>> On 4/21/10 7:32 PM, Steve Block wrote: >>>>> >>>>>> "Implementations that are unable to provide all three angles must >>>>>> set the values of the unknown angles to null" That is strange. The >>>>>> type of the property is double. That kind of properties don't >>>>>> usually give suddenly non-numeric values. >>>>> >>>>> There is precedent for this in the Geolocation spec. >>>> >>>> >>>> Sounds like a bug in Geolocation draft, IMO >>>> If the value isn't available, implementation could throw something >>>> like NOT_AVAILABLE. >>>> >>> >>> But then wouldn't you have to access all these properties from try / >>> catch blocks? I don't think that's ideal and it's just more convenient >>> to let them be null if they aren't available. >> >> And then all the callers need to check whether the returned value is >> null. And if (thevalue) isn't enough, because the value can be 0. >> >> I don't see how it is really more convenient to make it null in some >> cases. And making a double attribute null isn't something used in DOM >> Core for example. >> (Not all the things WebIDL specifies should be used, like PutForwards) >> >> -Olli >> > > But I could still add that I don't care too much about this issue. > It is just very ugly, and API wise rather inconsistent if some > double attributes can suddenly become null. > Yeah, question of taste, I guess. I don't see it as ugly and I am not convinced that changing the API to throw buys us anything. Andrei
Received on Thursday, 22 April 2010 10:27:36 UTC