On Mon, Jul 22, 2013 at 10:28 AM, Allen Wirfs-Brock
<allen at wirfs-brock.com> wrote:
>
> On Jul 22, 2013, at 9:42 AM, Jonas Sicking wrote:
>
>> On Mon, Jul 22, 2013 at 7:42 AM, Allen Wirfs-Brock
>> <allen at wirfs-brock.com> wrote:
>>>
>>>
>>> 3.  Is it ever appropriate for a DOM API to accept and retain a reference to
>>> a Date object?
>>
>> We could even generalize it to:
>>
>> 3. Is it ever appropriate for a DOM API to accept a reference to a Date object.
>>
>> Even if we just take a snapshot of the value returned by .getTime()
>> and retain that snapshot, is that really beneficial to taking a
>> numeric timestamp?
>>
>> The feedback in this thread seems to indicate "no" on all three?
>
> 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:
>
> 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.

Makes sense. And in fact, like Dominic points out, that will simply
follow automatically when accepting a numeric timestamp since WebIDL
will always use ToNumber to coerce any passed in value to a number.

> 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.

The emails in this thread seems to indicate that we should in fact not
return Date objects ever (though like any rule, I could imagine there
being exceptions). Instead we should simply return numeric timestamps.

However, we should of course expect other APIs, such as ones in JS
libraries, will use Date objects. The best ways to deal with that is
through your rule 1) above. I.e. accepting Date objects in addition to
numeric timestamps in input.

/ Jonas

On Mon, Jul 22, 2013 at 10:28 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> 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.

Makes sense. And in fact, like Dominic points out, that will simply
follow automatically when accepting a numeric timestamp since WebIDL
will always use ToNumber to coerce any passed in value to a number.

> 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.

The emails in this thread seems to indicate that we should in fact not
return Date objects ever (though like any rule, I could imagine there
being exceptions). Instead we should simply return numeric timestamps.

However, we should of course expect other APIs, such as ones in JS
libraries, will use Date objects. The best ways to deal with that is
through your rule 1) above. I.e. accepting Date objects in addition to
numeric timestamps in input.