On Monday, July 22, 2013, Jonas Sicking wrote:

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


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)?

Rick


> / Jonas
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <javascript:;>
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130722/ea827f76/attachment.html>

On Monday, July 22, 2013, Jonas Sicking wrote:

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


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)?