On Jan 20, 2013, at 4:42 PM, Brandon Benvie wrote:
> On Sunday, January 20, 2013, Allen Wirfs-Brock wrote:
> I'm not sure if you are getting at something other than what I've described
> above. If a @@DateValue private symbol is actually used as the
> implementation of [[DateValue]] then actuality that would happen.
>
> I explored implementing [[DateValue]], [[NumberValue]], etc. as symbols e.g.
> @@DateValue, but this causes observably different behavior from what is
> specified with a.) inheritance, and b.) interaction with proxies.
I spend a lot of time working of Date last week, so you don't have the latests.
In the case of inheritance at least, if it has observably different behavior it
hasn't been implemented correctly or the spec. is still buggy.
This is what my working draft currently says:
Unless explicitly stated otherwise, the methods of the Date prototype object
defined below are not generic and the this value passed to them must be an
object that has a [[DateValue]] internal data property that has been
initialized to a time value.
The abstract operation thisTimeValue(value) performs the following steps:
If Type(value) is Object and value has a [[DateValue]] internal data
property, then
Let n be the Number that is the value of value’s [[NumberData]]
internal data property.
If n is not undefined, then return n.
Throw a TypeError exception.
In following descriptions of functions that are properties of the Date
prototype object, the phrase “this Date object” refers to the object that is
the this value for the invocation of the function. The phrase “this time value”
within the specification of a method refers to the result returned by calling
the abstract operation thisTimeValue with the this value of the method
invocation passed as the argument.
>
> Object.create(new Date).getDate(); // works but is specified to not work
If you are using a private Symbol for [[DateValue]] then the "has a
[[DateValue]] internal data property" check in the above code needs to do a
[[HasOwnProperty]] check rather than a [[HasProperty]]
>
> new Proxy(new Date, {}).getDate(); // works but is specified to not work
Not sure why this works in you implementation. Can you explain.
>
> Since Proxy is new in ES6 this of course can still be fixed, but to make the
> first case work would be a (probably benign) backward incompatible change and
> isn't going to work cross-engine unless the spec is changed to explicitly
> allow/require it.
Right, everything is still in flux which is why it is great that you are trying
these things.
Allen_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
