Let RTCCertificate.expires have type DOMTimeStamp

[foolip]

http://w3c.github.io/webrtc-pc/#rtccertificate-interface

Is it the intention that this attribute return the same object every time, or a new object every time? It is generally frowned upon to have APIs where obj.attr==obj.attr doesn't hold true, so using [SameObject] would be most neutral choice here.

[martinthomson]

If you refer to the expires attribute, I don't think that's possible:

Platform objects returning an ECMAScript Date object from attributes or operations do not hold on to a reference to the Date object. A script that modifies a Date object so retrieved cannot affect the platform object it was retrieved from.

-- http://heycam.github.io/webidl/#es-Date

[henbos]

Wouldn't it make more sense for cases like this if expires was a getter method expires()? Then it's not strange that you get a new object every time.

[martinthomson]

That suggests that Date should never be used for an attribute. I think that's a bit strange. I prefer to instead think of Date as being special (like an int or long).

[henbos]

I'm suggesting that any time we want something to be read-only, so we make that something return defensive copies of itself, should be a method and not an attribute. If we have a Date that is not read-only then exposing it as an attribute makes sense. But implementing method behavior on (seemingly) non-methods, like attributes, also seems strange. I would argue strange-er.

Though I'm a total javascript and spec newbie so I don't know how things are normally done and I could be confused about something :), but it sounds broken to me atm.

[alvestrand]

So it seems that WebIDL requires returning defensive copies, that obj.dateAttribute !== obj.dateAttribute unless the platform does special tricks, and that programmers should just learn to live with it :-)

(in other news, == should die....)

[alvestrand]

so the code that we can't have looks like this:
a = cert.expires
a.setTime(17) // is legal script
cert.expires == Date(17) must NOT return true; in fact cert.expires == a must NOT return true.
We're in "defensive copies are needed" land. Sigh.

[henbos]

Interesting. By the way, I'm not against defensive copies, I'm against attributes that act like methods, sounds like that would be against how javascript is supposed to work, language-wise. Having cert.expires this way is like having a pointer in C++ or a reference variable in java that changed value every time you read from it. It's like... that's not how pointers/references are supposed to work in that language. And neither are attributes (because they're just "vars", right?). But if "cert.expires" changed to "cert.expires()" everything would make sense. Unless I'm speaking out of ignorance, which is a possibility (note: I'm not a javascript programmer!).

Anyway that's my two cents, I'll leave the discussion to you guys. Cheers.

[martinthomson]

@henbos, I generally agree, but if you have to concede that an integer attribute is returned by value, why not accept that Date is special in the same fashion? It's just another ---ed up quirk of JavaScript.

[henbos]

@martinthomson Because an integer really is a special case according to the language whereas a Date is an object (just like primitive types and objects are handled differently in Java), and because the equality would still hold for the integer comparison. If this was an integer nothing would be strange. I feel like this "JavaScript quirk" in particular was introduced by us; not inherent by the language. But yeah, JavaScript is pretty ---ed up.

If we were able to obtain a similar behavior in say Java, our API would be filed as a JVM bug. (A variable acting like a "return new Something();" method). I see this as the same thing, but maybe I'm confused about what attributes are in JavaScript. If attributes are more than mere variables then getting method-like behavior wouldn't be as strange to me. But that's not what they're supposed to be, right? :S

[foolip]

This isn't the first attribute on the web platform that returns a new object every time it is accessed, there's also HTMLMediaElement.buffered and a similar case in MSE where @bzbarsky filed a bug:
w3c/media-source#16

In other words, it's frowned upon at least some of the time, even if all cases haven't been solved.

As for Date-returning attributes and functions in the web platform, I can find these via Blink's IDL files:

• File.lastModifiedDate in an older version of the File API, now replaced with a long long lastModified attribute. @arunranga made the spec change and must know why.
• HTMLInputElement.valueAsDate attribute.
• Metadata.modificationTime attribute in an abandoned filesystem spec.
• RTCStats.timestamp attribute which isn't actually a Date per spec.

For a more recent and not-yet-implemented example, there's the HTMLMediaElement.getStartDate() function.

Based on all of this, I would recommend either a function returning Date or using some other type to represent the date, maybe long long.

[foolip]

@domenic, returning new objects from attributes and how to represent dates both seem like something that might be useful in https://w3ctag.github.io/design-principles/

[bzbarsky]

So a few things:

1. The Date type in IDL is generally acknowledged to be a mistake, for the various reasons mentioned above. See also https://www.w3.org/Bugs/Public/show_bug.cgi?id=22824 which has links to the various discussion on the issue, as well as some discussion about how to handle dates in APIs. That discussion is also what led to the change to File API, as I recall. The valueAsDate mess on HTMLInputElement we're stuck with, but it's more of a cautionary tale than an example to follow. As @foolip mentions, that and the deprecated File.lastModifiedDate are the only uses of Date in the web platform right now other than the one under discussion in this issue and we shouldn't be adding new ones. At least Gecko is not shipping this yet, so maybe we can avoid doing so at all (and ship long long instead).

2. Returning a new object each time from a getter is an API design no-no, indeed.

[alvestrand]

So should I change the subject line of this bug to be "Should RTCCertificate.expires have type "long long"?

[martinthomson]

@alvestrand yes

[foolip]

The guidance in https://w3ctag.github.io/design-principles/#times-and-dates makes sense to me, so I'll change the issue title to suggest using DOMTimeStamp instead.