Please do not use the Date type in Web IDL APIs

[Boris Zbarsky]

This is especially a reminder to reviewers, but also to anyone
participating in spec discussions. For context, see
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=22824>. You should
consider the Date type deprecated and not use it in new specifications.
You should _especially_ not create attributes of type Date.

-Boris

[Martin Thomson]

On Fri, Oct 16, 2015 at 6:39 AM, Boris Zbarsky <bzba...@mit.edu> wrote:
> You should _especially_ not create attributes of type Date.

Well, that's interesting. I think that I might have to eat crow:
https://github.com/w3c/webrtc-pc/issues/324

I didn't read all the discussion, but what is wrong with treating Date
as a primitive type that happens to have methods? I know that it
likely sucks to have all that custom code, but I've seen worse.

[Jonas Sicking]

Should we try to remove support for "Date" from our webidl implementation?

There's relatively few uses of it in our tree. Many are from tests,
and most of the remaining ones are from FirefoxOS certified APIs which
can be changed easily changed.

And in a few of the remaining cases we can change from using Date to
using a number since IIRC JS automatically converts Date objects to
numbers through the valueOf feature?

Main remaining ones that stand our are HTMLInputElement.valueAsDate
and File.lastModifiedDate. Both of which we'd need to get telemetry on
before we can remove I think.

http://mxr.mozilla.org/mozilla-central/search?string=Date&case=1&find=\.webidl%24

/ Jonas

On Fri, Oct 16, 2015 at 6:39 AM, Boris Zbarsky <bzba...@mit.edu> wrote:

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[Jonas Sicking]

On Fri, Oct 16, 2015 at 9:20 AM, Martin Thomson <m...@mozilla.com> wrote:
> On Fri, Oct 16, 2015 at 6:39 AM, Boris Zbarsky <bzba...@mit.edu> wrote:

>> You should _especially_ not create attributes of type Date.
>
>

> Well, that's interesting. I think that I might have to eat crow:
> https://github.com/w3c/webrtc-pc/issues/324
>
> I didn't read all the discussion, but what is wrong with treating Date
> as a primitive type that happens to have methods? I know that it
> likely sucks to have all that custom code, but I've seen worse.

The problem is that they are mutable objects, with no way to make them
immutable.

So you can do:

file.lastModifiedDate.setYear(3015);

Which means that any other consumers will now see the "wrong" date.
And if you change the attribute getter to return a new Date object
each time, then

file.lastModifiedDate == file.lastModifiedDate;

returns false which is surprising.

/ Jonas

[Boris Zbarsky]

On 10/16/15 12:20 PM, Martin Thomson wrote:
> https://github.com/w3c/webrtc-pc/issues/324

Yes, that is what prompted my mail. ;)

> I didn't read all the discussion, but what is wrong with treating Date
> as a primitive type that happens to have methods?

The fact that in JS it's not? It's an object. That's just the way that
particular part of the JS standard library works.

> I know that it
> likely sucks to have all that custom code, but I've seen worse.

I'm not sure what custom code you're talking about. What exactly are
you proposing?

-Boris

[Boris Zbarsky]

On 10/16/15 12:23 PM, Jonas Sicking wrote:
> Should we try to remove support for "Date" from our webidl implementation?

I would love to do that, yet. Getting there might be complicated.

> There's relatively few uses of it in our tree. Many are from tests,
> and most of the remaining ones are from FirefoxOS certified APIs which
> can be changed easily changed.

I'll believe that when I see it. I've had no luck getting people to
remove Date usage from those APIs in the past.

> And in a few of the remaining cases we can change from using Date to
> using a number since IIRC JS automatically converts Date objects to
> numbers through the valueOf feature?

Yes.

> Main remaining ones that stand our are HTMLInputElement.valueAsDate
> and File.lastModifiedDate. Both of which we'd need to get telemetry on
> before we can remove I think.

The latter, yes.

The former we can't remove because there is no replacement, even. But
if that's literally the only user (and not likely to change because the
editor of HTML thinks it's not a problem to violate all sorts of JS best
practices, including this one) we can nix Date from IDL and just have
this be "object" in IDL, with the Date object creation in HTMLInputElement.

-Boris

[Anne van Kesteren]

On Fri, Oct 16, 2015 at 6:33 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
> On 10/16/15 12:23 PM, Jonas Sicking wrote:
>> Should we try to remove support for "Date" from our webidl implementation?
>
> I would love to do that, yet. Getting there might be complicated.

We could maybe special case the existing usage and prevent new usage?


--
https://annevankesteren.nl/

[Boris Zbarsky]

On 10/16/15 12:54 PM, Anne van Kesteren wrote:
> We could maybe special case the existing usage and prevent new usage?

Yes. Most simply by renaming it in our bindings to LegacyDateDoNotUse. ;)

But that involves reviewers catching new uses, hence this thread.

-Boris

[Bobby Holley]

How about renaming it in our webidl to the same thing?

[Martin Thomson]

On Fri, Oct 16, 2015 at 9:30 AM, Boris Zbarsky <bzba...@mit.edu> wrote:
> I'm not sure what custom code you're talking about. What exactly are you
> proposing?

Date is fundamentally just an integer when you get down to it. Treat
it like one. An integer value is copied when you return it, so
modifications don't affect the underlying structure.

[Boris Zbarsky]

Integer values also do structural ==, not object identity ==. And can't
be mutated (mutating actually just creates a new value)

You seem to be arguing that Date should really be a value type in ES.
That's an argument I'm sympathetic to, but that's not the Date we have
right now.

So if you want to have value type like behavior, use a value type; for
now long long (in IDL terms; Number in JS terms) is good. If you want
to have a possibly-shared reference to a mutable thing, then Date makes
sense. Once ES grows actual value types, we can think about doing
something like that for date return values in APIs.

-Boris

[Martin Thomson]

WFM. I'll see what I can do about fixing RTCCertificate. I think
that the breakage should be minimal if I just change it.

[Jonas Sicking]

On Fri, Oct 16, 2015 at 11:44 AM, Boris Zbarsky <bzba...@mit.edu> wrote:
> So if you want to have value type like behavior, use a value type; for now
> long long (in IDL terms; Number in JS terms) is good

FWIW, when the problems with using Date objects in attributes were
raised with TC39, their recommendation after some debating was to do
the above.

/ Jonas

[Domenic Denicola]

I've added this and other related guidance to https://w3ctag.github.io/design-principles/#times-and-dates, which might help as a reference for if/when this comes up again. (Suggested fixes or elaborations welcome.)

I also opened https://github.com/heycam/webidl/issues/66 to see if we can make this more clear on the spec level.