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

Re: A proposal for parameter style

From: Ricardo Varela <phobeo@gmail.com>
Date: Wed, 28 Apr 2010 15:55:01 +0100
Message-ID: <z2jbfbd93661004280755paffa272cmacb523903b3a3c24@mail.gmail.com>
To: Frederick Hirsch <frederick.hirsch@nokia.com>
Cc: ext John Kemp <john@jkemp.net>, Robin Berjon <robin@robineko.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Just for consideration: wouldn't this make the syntax highlight and
contextual code completion/help for functions used by most IDEs a bit
of a hard task?

Saludos!

---
ricardo

On Wed, Apr 28, 2010 at 2:55 PM, Frederick Hirsch
<frederick.hirsch@nokia.com> wrote:
> +1
>
> This approach would also enable extensibility of Javascript methods with
> additional parameters added later if needed without necessarily breaking
> previous usage.   Requiring callbacks at the end would not allow this, isn't
> that true?
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
>
> On Apr 28, 2010, at 9:24 AM, ext John Kemp wrote:
>
>> On Apr 28, 2010, at 6:00 AM, Robin Berjon wrote:
>>
>>> Hi all,
>>>
>>> as you will recall, during the face to face in Prague we discussed the
>>> possibility of switching a lot of our API calls (mostly the asynchronous
>>> ones) to object literal rather than positional. This was generally perceived
>>> favourably but we resolved to first ask Geo why they hadn't opted for the
>>> same. Andrei kindly replied[0].
>>>
>>> Geo felt that for them, passing options would not be the most common case
>>> so that getCurrentPostion(scb) would beat getCurrentPostion({ success:
>>> scb}). Upon reflection, I think that our situation is more complex. Some of
>>> our APIs are more likely to have options on a very regular, even systematic
>>> basis (e.g. Contacts), and it wouldn't hurt to have a little consistency.
>>> I'd therefore like to propose that we go for object literal on all of our
>>> asynchronous calls.
>>>
>>> WDYT?
>>
>> +1 to your proposal.
>>
>> Using object literal "schema" for all API parameters would be most
>> consistent and allows for named parameters to appear in any order rather
>> than requiring a developer to get the order correct to call the function
>> correctly. The success and error callbacks could then have standard names
>> across the API, making it even easier for developers to remember what to do.
>>
>> Regards,
>>
>> - johnk
>>
>>>
>>>
>>>
>>> [0]http://www.w3.org/mid/n2n708552fb1004071110x6d98c6e6t85e83eef0eef52de@mail.gmail.com
>>>
>>> --
>>> Robin Berjon
>>> robineko — hired gun, higher standards
>>> http://robineko.com/
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>



-- 
Ricardo Varela  -  http://phobeo.com  -  http://twitter.com/phobeo
"Though this be madness, yet there's method in 't"
Received on Wednesday, 28 April 2010 14:55:35 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:43 UTC