<br><br>On Monday, July 22, 2013, Jonas Sicking  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Jul 22, 2013 at 10:28 AM, Allen Wirfs-Brock<br>
<<a href="javascript:;" onclick="_e(event, 'cvml', 'allen@wirfs-brock.com')">allen@wirfs-brock.com</a>> wrote:<br>
><br>
> On Jul 22, 2013, at 9:42 AM, Jonas Sicking wrote:<br>
><br>
>> On Mon, Jul 22, 2013 at 7:42 AM, Allen Wirfs-Brock<br>
>> <<a href="javascript:;" onclick="_e(event, 'cvml', 'allen@wirfs-brock.com')">allen@wirfs-brock.com</a>> wrote:<br>
>>><br>
>>><br>
>>> 3.  Is it ever appropriate for a DOM API to accept and retain a reference to<br>
>>> a Date object?<br>
>><br>
>> We could even generalize it to:<br>
>><br>
>> 3. Is it ever appropriate for a DOM API to accept a reference to a Date object.<br>
>><br>
>> Even if we just take a snapshot of the value returned by .getTime()<br>
>> and retain that snapshot, is that really beneficial to taking a<br>
>> numeric timestamp?<br>
>><br>
>> The feedback in this thread seems to indicate "no" on all three?<br>
><br>
> However, just like you you guys trying to define DOM APIs, many JavaScript programmers will not be aware of these subtleties and expect to be able to use Date objects with these APIs.  I would suggest, the following conventions:<br>

><br>
> 1)  APIs should accept Date objects as inputs, but when doing do so they should only retain and use the timevalue wrapped by the date object.<br>
<br>
Makes sense. And in fact, like Dominic points out, that will simply<br>
follow automatically when accepting a numeric timestamp since WebIDL<br>
will always use ToNumber to coerce any passed in value to a number.<br>
<br>
> 2) APIs may return Date objects but they should always be newly created instances and never retain references to them.  An API client might mutate such returned Date objects but that's really the clients business  and it will have no impact upon the DOM.<br>

<br>
The emails in this thread seems to indicate that we should in fact not<br>
return Date objects ever (though like any rule, I could imagine there<br>
being exceptions). Instead we should simply return numeric timestamps.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
However, we should of course expect other APIs, such as ones in JS<br>
libraries, will use Date objects. The best ways to deal with that is<br>
through your rule 1) above. I.e. accepting Date objects in addition to<br>
numeric timestamps in input.</blockquote><div><br></div><div><span style>Yes, just as I said very early on in this thread (with regard to returned values). Is it possible to retroactively apply Allen's recommendation to existing APIs that accept  one or the other, allowing them to accept both as the same? Is it worth doing so (it may not be)?</span><br>
</div><div><span style><br></span></div><div><span style>Rick<span></span></span></div><div><span style><br></span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
/ Jonas<br>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'es-discuss@mozilla.org')">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote>