Re: A proposal for parameter style

+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/
>>
>>
>>
>>
>>
>
>

Received on Wednesday, 28 April 2010 13:56:23 UTC