W3C home > Mailing lists > Public > public-geolocation@w3.org > April 2010

Re: Orientation event draft

From: Andrei Popescu <andreip@google.com>
Date: Thu, 22 Apr 2010 11:26:41 +0100
Message-ID: <p2w708552fb1004220326g3105f42bxa84e259328514b45@mail.gmail.com>
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.

Received on Thursday, 22 April 2010 10:27:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:56 UTC