Re: [Alarm] respectTimezone

On Wednesday, 13 February 2013 at 20:51, Mounir Lamouri wrote:

> On 12/02/13 07:31, Christophe Dumez - SISA wrote:
> > Hi Marcos,
> > 
> > I fully support this proposal. If we make the respectTimezone argument optional, then it makes a lot of sense to use a dictionary for respectTimezone and the custom data since they would both be optional. Then, we can use a boolean for respectTimezone indeed.
> > 
> > I also think that respectTimezone should be set to True by default.
> > 
> > Anyone has any objection to this change?
> 'respectTimezone' and 'ignoreTimezone' isn't a simple concept, this is
> why we decided to have it mandatory and as explicit strings instead of
> booleans.
> 
> Indeed, most developers will use 'respectTimezone' but those who will
> have to use 'ignoreTimezone' might not even think of it if the API isn't
> explicit enough. Making the argument explicit reduces the chance of
> developers shooting themselves in the foot. Hiding the argument inside a
> dictionary might even be worse in this regard.

But you are punishing all developers for the sins of the few. Like most JS, how these APIs get used will simply come down to copy/pasting from MDN and the like. If you are really worried, then make sure your documentation is clear and that all your examples explicitly have either "respectTimezone" and "ignoreTimezone" set (and pray that W3Schools does the same ;) ). 

And I really don't see the correlation between forcing people to type "respectTimezone" and "ignoreTimezone" and them actually understanding, or bothering to go and look up, what those mean/do. As most developer do, they will just test and see if it works and move onto something else. Eventually some poor user will not get woken at the right time, yell at the developer, which will then add the correct flag. 

It would probably be the same with something like addEventListener(). Imagine the last argument was "useCapture" and "dontCapture" - sure, those are legible, but you'd be hard pressed to find people who can articulate what those mean. And having them there does not guarantee anyone will take up the scholarly pursuit of understanding event bubbling and capturing (fascinating as it is) until something breaks.  

-- 
Marcos Caceres
http://datadriven.com.au

Received on Thursday, 14 February 2013 12:31:22 UTC