Re: Number.isNaN

[Andreas Rossberg]

On 14 December 2012 06:46, John-David Dalton
 wrote:
>Axel Rauschmayer:
>> Honest question: I have yet to see boxed values in practice. Are there any
>> real use cases?
>
> See Modernizr:
> https://github.com/Modernizr/Modernizr/blob/master/feature-detects/video.js#L23

I think not. And wrapping bools, like the above piece of code does, is
a particularly bad idea, because JS says

  (Object(false) ? 1 : 2)  ===  1

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: A DOM use case that can't be emulated with direct proxies

[Brendan Eich]

Mark S. Miller wrote:
On Thu, Dec 13, 2012 at 7:05 PM, Brendan Eich  wrote: 

Boris Zbarsky pointed out on public-script-coord that window.location and 

window.document must be non-configurable _ab initio_, but perhaps this is 


achievable with direct proxies?


This resolved into two suggestions, both consistent with ES5 and with
direct proxies:

* windows.document and window.location must refuse to be configured,
but they can still claim to be configurable. ES5 purposely forbids
only the opposite mismatch: They can't claim to be non-configurable
but still change state in ways that violate that claim.

* Allen suggested that these could be non-configurable getter-only
accessor properties,


window.location can be set by assignment to navigate to a new URL. Yet 
it appears in Chrome, Firefox, Opera, and Safari to be a writable data 
property. In any event, it can't be a getter-only accessor.


/be


  where the getter stays the same and the magic
"switching" behavior is in the getter. (My words for Allen's
suggestion)

Either is fine. I like Allen's better.

--
 Cheers,
 --MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: A DOM use case that can't be emulated with direct proxies

[Brendan Eich]

David Bruant wrote:

Le 12/12/2012 21:42, Kevin Reid a écrit :
On Wed, Dec 12, 2012 at 12:35 PM, David Bruant > wrote:


I was a bit too strong in my statement, sorry. Let me rephrase:
the internal [[Target]] can't be changed, but a proxy can emulate
changing of "fake" target as long as what happens with this
"fake" target doesn't involve invariant checking.
That's the reason I was suggesting that WindowProxies could
(maybe depending on how the object reference was obtained) throw
whenever invariant checks are involved.


Exactly. So a user-defined switching proxy needs only to:
1. refuse to commit to any invariant (non-configurable property or 
preventExtensions)
2. even if its switchable-target has an invariant, do not expose that 
invariant (i.e. pretend each property is configurable)
Pretend that something non-configurable actually is configurable is an 
invariant violation. To be more concrete:

* There is an webpage with an iframe
* The same window object is proxied by 2 WindowProxy instances. One 
outside the iframe, one inside.


Just as a point of fact regarding the web-as-it-is, this can't happen, 
right? There's only one WindowProxy per Window and it is the only object 
referenced by any JS variable. JS code cannot construct another aliasing 
WindowProxy.


* Inside of the iframe, scripts can add a non-configurable property 
"azerty" to their global.


Boris Zbarsky pointed out on public-script-coord that window.location 
and window.document must be non-configurable _ab initio_, but perhaps 
this is achievable with direct proxies?


/be

* Outside the iframe, what happens when 
Object.getOwnPropertyDescriptor(iframeWindow, 'azerty') is called?
You're suggesting that {configurable: true} is returned. The problem 
is that on the actual Window instance, there is a non-configurable 
property, so if the WindowProxy handler tries to do that, an error 
will be thrown because of invariant checks.


I think throwing is the correct behavior here. The handler can't tell 
the truth about non-configurable properties (because a later different 
target may not have the same non-configurable properties), but also 
can't lie, because lies involves throwing... well, since I say that 
throwing is the correct behavior, I guess lying is too in a way.


David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Number.isNaN

[John-David Dalton]

> Honest question: I have yet to see boxed values in practice. Are there
any real use cases?

See Modernizr:
https://github.com/Modernizr/Modernizr/blob/master/feature-detects/video.js#L23

-JDD


On Thu, Dec 13, 2012 at 8:26 PM, Axel Rauschmayer  wrote:

> Honest question: I have yet to see boxed values in practice. Are there any
> real use cases?
>
> [[[Sent from a mobile device. Please forgive brevity and typos.]]]
>
> Dr. Axel Rauschmayer
> a...@rauschma.de
> Home: http://rauschma.de
> Blog: http://2ality.com
>
> On 14.12.2012, at 05:18, Luke Hoban  wrote:
>
> >>> From: Mark S. Miller [mailto:erig...@google.com]
> >>>
> >>> In that case, the current spec is wrong. The purpose of introducing
> Number.isNaN is to repair the >> following bug in the global isNaN:
> >>>
> >>>isNaN("foo") // returns true
> >
> > Indeed, as Yusuke noted on the other reply, I referred to the wrong
> 'isNaN'.  And as you note, the point of the 'Number.isNaN' variant is to
> avoid any coercions.
> >
> > That still leave's JDD's original suggestion to allow
> Number.isNaN(Object(NaN)) to return 'true' by checking for either primitive
> or boxed Number.  It feels a little odd to introduce another kind of
> limited coercion into the language, but perhaps it is practically valuable
> to not differentiate boxed and unboxed numbers here?
> >
> > Luke
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Number.isNaN

[John-David Dalton]

> No. Object.is correctly reports that these are different.

Ah yap, I've had my head in lib code for a while. I'm used to the behavior
of `_.isEqual(3, Object(3)); // => true`
but you're right the current behavior of `Object.is(3, Object(3)); //
false` so yap it makes sense that it's that way for `NaN` and `Object(NaN)`
as well.


On Thu, Dec 13, 2012 at 8:36 PM, Mark S. Miller  wrote:

> On Thu, Dec 13, 2012 at 8:25 PM, John-David Dalton
>  wrote:
> > Yap yap, so thoughts on `BuiltinNumberWrapper` instead of `Type(…)`? It
> > would still prevent the global `isNaN('foo')` confusion. Though
> > `Object.is(NaN, Object(NaN))` currently returns `false` too. Was this
> just
> > an oversight?
>
> No. Object.is correctly reports that these are different.
>
>
> > I know `Object(NaN)` is totally edge case but it still has the
> > brand of BultinNumberWrapper and is NaN (boxed).
> >
> >
> >
> > On Thu, Dec 13, 2012 at 8:18 PM, Luke Hoban  wrote:
> >>
> >> >> From: Mark S. Miller [mailto:erig...@google.com]
> >> >>
> >> >> In that case, the current spec is wrong. The purpose of introducing
> >> >> Number.isNaN is to repair the >> following bug in the global isNaN:
> >> >>
> >> >> isNaN("foo") // returns true
> >>
> >> Indeed, as Yusuke noted on the other reply, I referred to the wrong
> >> 'isNaN'.  And as you note, the point of the 'Number.isNaN' variant is to
> >> avoid any coercions.
> >>
> >> That still leave's JDD's original suggestion to allow
> >> Number.isNaN(Object(NaN)) to return 'true' by checking for either
> primitive
> >> or boxed Number.  It feels a little odd to introduce another kind of
> limited
> >> coercion into the language, but perhaps it is practically valuable to
> not
> >> differentiate boxed and unboxed numbers here?
> >>
> >> Luke
> >>
> >
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
>
>
> --
> Cheers,
> --MarkM
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Number.isNaN

[Mark S. Miller]

On Thu, Dec 13, 2012 at 8:25 PM, John-David Dalton
 wrote:
> Yap yap, so thoughts on `BuiltinNumberWrapper` instead of `Type(…)`? It
> would still prevent the global `isNaN('foo')` confusion. Though
> `Object.is(NaN, Object(NaN))` currently returns `false` too. Was this just
> an oversight?

No. Object.is correctly reports that these are different.


> I know `Object(NaN)` is totally edge case but it still has the
> brand of BultinNumberWrapper and is NaN (boxed).
>
>
>
> On Thu, Dec 13, 2012 at 8:18 PM, Luke Hoban  wrote:
>>
>> >> From: Mark S. Miller [mailto:erig...@google.com]
>> >>
>> >> In that case, the current spec is wrong. The purpose of introducing
>> >> Number.isNaN is to repair the >> following bug in the global isNaN:
>> >>
>> >> isNaN("foo") // returns true
>>
>> Indeed, as Yusuke noted on the other reply, I referred to the wrong
>> 'isNaN'.  And as you note, the point of the 'Number.isNaN' variant is to
>> avoid any coercions.
>>
>> That still leave's JDD's original suggestion to allow
>> Number.isNaN(Object(NaN)) to return 'true' by checking for either primitive
>> or boxed Number.  It feels a little odd to introduce another kind of limited
>> coercion into the language, but perhaps it is practically valuable to not
>> differentiate boxed and unboxed numbers here?
>>
>> Luke
>>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Number.isNaN

[Axel Rauschmayer]

Honest question: I have yet to see boxed values in practice. Are there any real 
use cases?

[[[Sent from a mobile device. Please forgive brevity and typos.]]]

Dr. Axel Rauschmayer
a...@rauschma.de
Home: http://rauschma.de
Blog: http://2ality.com

On 14.12.2012, at 05:18, Luke Hoban  wrote:

>>> From: Mark S. Miller [mailto:erig...@google.com] 
>>> 
>>> In that case, the current spec is wrong. The purpose of introducing 
>>> Number.isNaN is to repair the >> following bug in the global isNaN:
>>> 
>>>isNaN("foo") // returns true
> 
> Indeed, as Yusuke noted on the other reply, I referred to the wrong 'isNaN'.  
> And as you note, the point of the 'Number.isNaN' variant is to avoid any 
> coercions.  
> 
> That still leave's JDD's original suggestion to allow 
> Number.isNaN(Object(NaN)) to return 'true' by checking for either primitive 
> or boxed Number.  It feels a little odd to introduce another kind of limited 
> coercion into the language, but perhaps it is practically valuable to not 
> differentiate boxed and unboxed numbers here?
> 
> Luke
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Number.isNaN

[John-David Dalton]

Yap yap, so thoughts on `BuiltinNumberWrapper` instead of `Type(…)`? It
would still prevent the global `isNaN('foo')` confusion. Though
`Object.is(NaN, Object(NaN))` currently returns `false` too. Was this just
an oversight? I know `Object(NaN)` is totally edge case but it still has
the brand of BultinNumberWrapper and is NaN (boxed).


On Thu, Dec 13, 2012 at 8:18 PM, Luke Hoban  wrote:

> >> From: Mark S. Miller [mailto:erig...@google.com]
> >>
> >> In that case, the current spec is wrong. The purpose of introducing
> Number.isNaN is to repair the >> following bug in the global isNaN:
> >>
> >> isNaN("foo") // returns true
>
> Indeed, as Yusuke noted on the other reply, I referred to the wrong
> 'isNaN'.  And as you note, the point of the 'Number.isNaN' variant is to
> avoid any coercions.
>
> That still leave's JDD's original suggestion to allow
> Number.isNaN(Object(NaN)) to return 'true' by checking for either primitive
> or boxed Number.  It feels a little odd to introduce another kind of
> limited coercion into the language, but perhaps it is practically valuable
> to not differentiate boxed and unboxed numbers here?
>
> Luke
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Number.isNaN

[Luke Hoban]

>> From: Mark S. Miller [mailto:erig...@google.com] 
>>
>> In that case, the current spec is wrong. The purpose of introducing 
>> Number.isNaN is to repair the >> following bug in the global isNaN:
>>
>> isNaN("foo") // returns true

Indeed, as Yusuke noted on the other reply, I referred to the wrong 'isNaN'.  
And as you note, the point of the 'Number.isNaN' variant is to avoid any 
coercions.  

That still leave's JDD's original suggestion to allow Number.isNaN(Object(NaN)) 
to return 'true' by checking for either primitive or boxed Number.  It feels a 
little odd to introduce another kind of limited coercion into the language, but 
perhaps it is practically valuable to not differentiate boxed and unboxed 
numbers here?

Luke

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Number.isNaN

[Yusuke Suzuki]

>
> The current draft spec [0] uses a ToNumber coercion and checks whether
> this results is NaN.  So "Number.isNaN(Object(NaN))" will return "true".

Global's isNaN uses ToNumber, but Number.isNaN doesn't do it because type
coercion makes confused result, such as `isNaN(Object(NaN))` => true [0]

So "Number.isNaN(Object(NaN))" will return "false" in latest draft and
"isNaN(Object(NaN))"
will return "true".

[0] http://wiki.ecmascript.org/doku.php?id=harmony:number.isnan



On Fri, Dec 14, 2012 at 12:50 PM, Luke Hoban  wrote:

> >> From: es-discuss-boun...@mozilla.org [mailto:
> es-discuss-boun...@mozilla.org] On Behalf Of John-David Dalton
> >> Subject: Number.isNaN
>
> >> I noticed that ES6  `Number.isNaN` checks `Type(number)` of Number,
> would it make sense to instead check that the [[BuiltinBrand]] is
> BuiltinNumberWrapper similar to `Array.isArray`'s check. This would also
> allow `Number.isNaN(Object(NaN))` to return `true`. Thoughts?
>
> The current draft spec [0] uses a ToNumber coercion and checks whether
> this results is NaN.  So "Number.isNaN(Object(NaN))" will return "true".
>
> Luke
>
> [0] http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Regards,
Yusuke Suzuki
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Number.isNaN

[Mark S. Miller]

On Thu, Dec 13, 2012 at 7:50 PM, Luke Hoban  wrote:
>>> From: es-discuss-boun...@mozilla.org 
>>> [mailto:es-discuss-boun...@mozilla.org] On Behalf Of John-David Dalton
>>> Subject: Number.isNaN
>
>>> I noticed that ES6  `Number.isNaN` checks `Type(number)` of Number, would 
>>> it make sense to instead check that the [[BuiltinBrand]] is 
>>> BuiltinNumberWrapper similar to `Array.isArray`'s check. This would also 
>>> allow `Number.isNaN(Object(NaN))` to return `true`. Thoughts?
>
> The current draft spec [0] uses a ToNumber coercion and checks whether this 
> results is NaN.  So "Number.isNaN(Object(NaN))" will return "true".

In that case, the current spec is wrong. The purpose of introducing
Number.isNaN is to repair the following bug in the global isNaN:

isNaN("foo") // returns true


>
> Luke
>
> [0] http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Number.isNaN

[Luke Hoban]

>> From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] 
>> On Behalf Of John-David Dalton
>> Subject: Number.isNaN

>> I noticed that ES6  `Number.isNaN` checks `Type(number)` of Number, would it 
>> make sense to instead check that the [[BuiltinBrand]] is 
>> BuiltinNumberWrapper similar to `Array.isArray`'s check. This would also 
>> allow `Number.isNaN(Object(NaN))` to return `true`. Thoughts?

The current draft spec [0] uses a ToNumber coercion and checks whether this 
results is NaN.  So "Number.isNaN(Object(NaN))" will return "true".

Luke

[0] http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: A DOM use case that can't be emulated with direct proxies

[Mark S. Miller]

On Thu, Dec 13, 2012 at 7:05 PM, Brendan Eich  wrote:
>
> Boris Zbarsky pointed out on public-script-coord that window.location and
> window.document must be non-configurable _ab initio_, but perhaps this is
> achievable with direct proxies?

This resolved into two suggestions, both consistent with ES5 and with
direct proxies:

* windows.document and window.location must refuse to be configured,
but they can still claim to be configurable. ES5 purposely forbids
only the opposite mismatch: They can't claim to be non-configurable
but still change state in ways that violate that claim.

* Allen suggested that these could be non-configurable getter-only
accessor properties, where the getter stays the same and the magic
"switching" behavior is in the getter. (My words for Allen's
suggestion)

Either is fine. I like Allen's better.

--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Number.isNaN

[John-David Dalton]

I noticed that ES6  `Number.isNaN` checks `Type(number)` of Number, would
it make sense to instead check that the [[BuiltinBrand]] is
BuiltinNumberWrapper similar to `Array.isArray`'s check. This would also
allow `Number.isNaN(Object(NaN))` to return `true`. Thoughts?

- JDD
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: A DOM use case that can't be emulated with direct proxies

[Brendan Eich]

Kevin Reid wrote:
(2) the proxy has to pretend that all inherited properties are 
actually own,


It strikes me that we need this for window objects anyway, to resolve

https://bugs.ecmascript.org/show_bug.cgi?id=78
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: A DOM use case that can't be emulated with direct proxies

[Kevin Reid]

On Thu, Dec 13, 2012 at 2:58 PM, David Bruant  wrote:

>  Le 13/12/2012 20:47, Jason Orendorff a écrit :
>
> David: https://gist.github.com/4279162
>
> I think this is what Kevin has in mind. Note in particular that the target
> of the Proxy is just a dummy object, and the handler ignores it entirely.
> The proxy uses it for invariant checks, but the intent is that those would
> always pass.
>
> but they do not; try:
>
> var [p, setTarget] = retargetableProxy({}); // I love destructuring
> sooo much!
> Object.defineProperty(p, 'a', {configurable: false, value:31});
>

In my proposal, this would fail ("refuse to commit to any invariant" as I
put it above). The handler specifically refuses anything non-configurable
or non-writable-data.


> setTarget({});
> Object.getOwnPropertyDescriptor(p, 'a'); // invariant check throws here
>
> Any variant that can be written will have the same issue. Even trickeries
> with the defineProperty trap.
> The proxy is enforcing invariants against the dummy [[target]]. The same
> is to be expected from WindowProxy instances even if their underlying
> window changes. It doesn't matter if the invariant is enforced on the dummy
> target on an actual window instance. It is enforced and that's the
> "problem" (with WindowProxy implemented as they are now not being emulable
> with proxies)
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: A DOM use case that can't be emulated with direct proxies

[David Bruant]

Le 13/12/2012 20:47, Jason Orendorff a écrit :
On Wed, Dec 12, 2012 at 3:44 PM, David Bruant > wrote:


Le 12/12/2012 22:30, Kevin Reid a écrit :

The JS runtime won't know that the proxy has anything to do with
the actual Window instance. The Proxy's formal target will be
just {};

This target, even if dummy, is the one that will be used for
invariants checks. You can't get away from this by design. This is
one of the most important part of the direct proxies design.
Even if you switch of fake target, the engine will still perform
checks on the dummy internal [[Target]].

I feel we're cycling in what we say and I feel I can't find the
right words to explain my point. One idea would be for you to
implement a target-switching proxy based on direct proxies
(Firefox has them natively or you can use Tom's shim [1]). I'm
confident you'll understand my point through this exercise.


David: https://gist.github.com/4279162

I think this is what Kevin has in mind. Note in particular that the 
target of the Proxy is just a dummy object, and the handler ignores it 
entirely. The proxy uses it for invariant checks, but the intent is 
that those would always pass.

but they do not; try:

var [p, setTarget] = retargetableProxy({}); // I love destructuring 
sooo much!

Object.defineProperty(p, 'a', {configurable: false, value:31});
setTarget({});
Object.getOwnPropertyDescriptor(p, 'a'); // invariant check throws here

Any variant that can be written will have the same issue. Even 
trickeries with the defineProperty trap.
The proxy is enforcing invariants against the dummy [[target]]. The same 
is to be expected from WindowProxy instances even if their underlying 
window changes. It doesn't matter if the invariant is enforced on the 
dummy target on an actual window instance. It is enforced and that's the 
"problem" (with WindowProxy implemented as they are now not being 
emulable with proxies)


David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: A DOM use case that can't be emulated with direct proxies

[Kevin Reid]

On Thu, Dec 13, 2012 at 11:47 AM, Jason Orendorff  wrote:

> This target, even if dummy, is the one that will be used for invariants
>> checks. You can't get away from this by design. This is one of the most
>> important part of the direct proxies design.
>> Even if you switch of fake target, the engine will still perform checks
>> on the dummy internal [[Target]].
>>
>> I feel we're cycling in what we say and I feel I can't find the right
>> words to explain my point. One idea would be for you to implement a
>> target-switching proxy based on direct proxies (Firefox has them natively
>> or you can use Tom's shim [1]). I'm confident you'll understand my point
>> through this exercise.
>>
>
> David: https://gist.github.com/4279162
>
> I think this is what Kevin has in mind. Note in particular that the target
> of the Proxy is just a dummy object, and the handler ignores it entirely.
> The proxy uses it for invariant checks, but the intent is that those would
> always pass.
>

Yes, exactly. I was just this minute in the process of writing such a proxy
myself, and have not yet confirmed whether it is accepted by the invariant
checks for all the cases I'm thinking of (testing against FF 18.0).

Note that either
(1) all the switched-among targets need to have the same [[Prototype]],
(2) the proxy has to pretend that all inherited properties are actually own,
(3) or mutating [[Prototype]] (i.e. __proto__) needs to be possible.
In my particular use case, (1) is not a suitable option, so I would
implement (2) if (3) is not available. Not that I approve of (3), but one
does what one must to accomplish virtualization.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: A DOM use case that can't be emulated with direct proxies

[Jason Orendorff]

On Wed, Dec 12, 2012 at 3:44 PM, David Bruant  wrote:

>  Le 12/12/2012 22:30, Kevin Reid a écrit :
>
>  The JS runtime won't know that the proxy has anything to do with the
> actual Window instance. The Proxy's formal target will be just {};
>
> This target, even if dummy, is the one that will be used for invariants
> checks. You can't get away from this by design. This is one of the most
> important part of the direct proxies design.
> Even if you switch of fake target, the engine will still perform checks on
> the dummy internal [[Target]].
>
> I feel we're cycling in what we say and I feel I can't find the right
> words to explain my point. One idea would be for you to implement a
> target-switching proxy based on direct proxies (Firefox has them natively
> or you can use Tom's shim [1]). I'm confident you'll understand my point
> through this exercise.
>

David: https://gist.github.com/4279162

I think this is what Kevin has in mind. Note in particular that the target
of the Proxy is just a dummy object, and the handler ignores it entirely.
The proxy uses it for invariant checks, but the intent is that those would
always pass.

-j
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: A DOM use case that can't be emulated with direct proxies

[Mark S. Miller]

Something I just posted in the public-script-coord thread bears repeating here:

A single invariant-violating object can be leveraged by direct proxies
to create any number of other objects that also violate invariants.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: A DOM use case that can't be emulated with direct proxies

[Mark S. Miller]

On Thu, Dec 13, 2012 at 1:12 AM, David Bruant  wrote:
>> I think this is the only viable solution.
>
> Ok. What do you think of the idea of different handlers based on context?
> [1]
>
> [1] Last point of
> https://mail.mozilla.org/pipermail/es-discuss/2012-December/027092.html

Only if these different way of obtaining the object actually obtain
different objects.



>
>> The current behavior violates ES5 in an unintended way[1].
>
> Just to clarify, invariants described in ES5.1 - 8.6.2 are violated.

yes.

>
>
>> As you say, to remain viable, it
>> must be done quickly. From previous experience, I suggest that there's
>> exactly one way to get quick universal deployment: add a test to
>> test262 that fails when a browser's WindowProxy object violates this
>> normative part of the ES5 spec.
>
> I feel such a test would rather belong to the HTML DOM. But either way, I
> agree.

The spec that it violates is ES5.1. Therefore it will be
uncontroversial to put such tests into test262. The modern versions of
all major browsers (IE, Chrome, FF, Safari, Opera) all do so close to
perfect on test262 that even adding one additional test failure
creates a significant incentive to fix it -- especially since the
others will.

Of course, it would also be good to get the HTML5 spec fixed and to
get such tests into HTML/DOM test suites. But I'm not holding my
breath. Your observation about needing to get this fixed soon in
right, so let's move on test262 first.



> I'll reach out to public-script-coord to re-explain the issue and the
> suggested changes. I'll write a test case, submit it to the webapps
> directory [2] (I'll ask first to be sure it's the right one) and file bugs
> in different browsers.

Thanks!

>
> David
>
> [2] http://dvcs.w3.org/hg/webapps/



--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ECMAScript Internationalization API approved

[Norbert Lindenberg]

Hi Alexandre,

Yes, there is an initial set of tests. It currently is part of test262 because 
it uses the test262 harness:
http://test262.ecmascript.org/testcases_intl402.html
http://hg.ecmascript.org/tests/test262/file/53c4ade82d14/test/suite/intl402

Regards,
Norbert


On Dec 13, 2012, at 1:50 , Alexandre Morgaut wrote:

> Great!
> 
> Is there already a planned test402 initiative (similar to test262)?
> 
> Regards,
> Alexandre
> 
> On 12 déc. 2012, at 19:28, Norbert Lindenberg wrote:
> 
>> István has informed me that the Ecma General Assembly today unanimously 
>> approved ECMA-402, ECMAScript Internationalization API Specification.
>> 
>> http://ecma-international.org/publications/standards/Ecma-402.htm
>> 
>> Norbert
>> 
>> 
> 
> 
> 
> Alexandre Morgaut
> Wakanda Community Manager
> 
> 4D SAS
> 60, rue d'Alsace
> 92110 Clichy
> France
> 
> Standard : +33 1 40 87 92 00
> Email :alexandre.morg...@4d.com
> Web :  www.4D.com
> 
> 
> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Confusion about different [[Scope]] between Function Declaration and Function Expression

[Brendan Eich]

Allen Wirfs-Brock wrote:

  Some implementations bind the function name scoped to the block others bind 
the name scoped to the enclosing function.


Detailed aside: no standard implementation actually binds to a block 
scope (yet -- this is proposed for ES6 and implementations are 
appearing, e.g. under a flag in V8 in Chrome).


Rather, the implementations bind the function "sub-statement" by its 
name in the outer function's activation but either always, as if hoisted 
independent of control flow (last in source order among several for the 
same name wins), or (SpiderMonkey in Firefox, Rhino, possibly others) 
binding the name as if by assignment if and only if control flow reaches 
the nested function declaration.


Web content relies on the intersection semantics. E.g.,

  function outer() {
...
if (cond) {
  function inner() { ... }
  obj.callback = inner;
}
...
  }

Fortunately, ES6's block-scoped semantics for functions declared in 
blocks is in this intersection.


/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Confusion about different [[Scope]] between Function Declaration and Function Expression

[Allen Wirfs-Brock]

ECMAScript 5.1 does not syntactically permit a FunctionDeclaration to directly 
appear nested within a Block.  The semantics provided by the specification are 
those for a function declaration at the top level of a function.  The only 
standard way to evaluate a function declaration within a nested lexical 
environment (established by either a with statement or a catch clause) is via a 
direct eval.  Direct eval uses the normal semantics for binding 
FunctionDeclaration so the function binds to the top level of the enclosing 
function.

Most ECMAScript implementation are extended (beyond what is in the standard) to 
allow a FunctionDeclaration to appear within a nested scope.  While this 
syntactic extension is common, there isn't a single common semantics for the 
extension.  Some implementations bind the function name scoped to the block 
others bind the name scoped to the enclosing function. Regardless, if an 
implementation supports inner scope syntactic FunctionDeclarations is makes 
sense that they would use the same semantics if the FunctionDeclaration is 
introduced via a direct eval call.  That is presumably what you are observing.

There may be a reasonable argument to be made that ES5.1 should be scoping such 
inner scope direct eval introduced FunctionDeclaration to the inner scope.  Or, 
that ES5.1 should not allow such declaration to be introduced via direct eval. 
However, the point will soon be moot as ES6 will allow inner scoped 
FunctionDeclarations and will provided a standard semantics that scopes them to 
the immediately inclosing scope.

Allen



On Dec 11, 2012, at 11:03 PM, Kang-Hao (Kenny) Lu wrote:

> (Resending on behalf of 张立理  because his mail
> didn't go through.)
> 
> According to [section 13 Function
> Definition](http://ecma-international.org/ecma-262/5.1/#sec-13) of
> ECMAScript-262 5.1, the **Function Declaration** production and the
> **Function Expression** production are nearly the same, except when they
> are in the process of [Create Function
> Objects](http://ecma-international.org/ecma-262/5.1/#sec-13.2), in which
> case they pass different **Scope** argument: Function Declaration passes
> the **VariableEnvironment** while Function Expression passes the
> **LexicalEnvironment**. This confuses me a little.
> 
> 
> Suppose we have this code:
> 
> 
>function test() {
>var x = 1;
>var o = { x: 2 };
>with (o) {
>eval('function foo() { console.log(x); }');
>eval('var bar = function() { console.log(x); }');
>}
>foo();
>bar();
>}
>test();
> 
> 
> If I understand correctly, here are 2 facts:
> 
> 
> - outside `with` statement, the **VariableEnvironment** and
> **LexicalEnvironment** refer to the same object, here we name it `outerEnv`.
> - inside `with` statement, we have a new **LexicalEnvironment** (object
> environment), the **VariableEnvironment** stays the same, here we name
> the new **LexicalEnvironment** `innerEnv`.
> 
> 
> The problem lies in the 2 direct `eval` calls. Without the **strict**
> flag, the `eval` function shares the same **LexicalEnvironment** and
> **VariableEnvironment** as its calling context. When the `eval` is
> invoked in a `with` statement, **VariableEnvironment** and
> **LexicalEnvironment** are different, so we expect `foo` and `bar`
> outputs different numbesr: `foo` should output `1` and `bar` should
> output `2`.
> 
> 
> The fact is, the edge version of Chrome, Firefox and IE7-10, all output
> `2` and `2`.
> 
> 
> Why is ECMAScript-262 5.1 documenting a behavior that's different from
> nearly all modern browsers? Should these browsers consider their
> implementations buggy, or should our standard change a little? Anyway, I
> could not image a situation when **Function Declaration** and **Function
> Expression** should use different objects as their `[[Scope]]` internal
> property, why not use **LexicalEnvironment** of its calling context as
> all browsers do?
> 
> 
> The `catch` statement has the same problem:
> 
> 
>function test() {
>var x = 1;
>try {
>throw 2;
>}
>catch (x) {
>eval('function foo() { console.log(x); }');
>eval('var bar = function() { console.log(x); }');
>}
>foo();
>bar();
>}
>test();
> 
> 
> Thanks.
> 
> 
> 
> Gray Zhang
> -
> 电子邮件：otakus...@live.com
> 微博：@otakustay
> 博客：http://otakustay.com
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Creating a filled array with a given length?

[Rick Waldron]

On Thu, Dec 13, 2012 at 4:14 AM, Jussi Kalliokoski <
jussi.kallioko...@gmail.com> wrote:

> [ ...Array(8) ].map( (v, i) => 1 << i )


That's awesome, check it out:
http://traceur-compiler.googlecode.com/git/demo/repl.html#%20%5B%20...Array(8)%20%5D.map(%20(v%2C%20i)%20%3D%3E%201%20%3C%3C%20i%20)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ECMAScript Internationalization API approved

[Alexandre Morgaut]

Great!

Is there already a planned test402 initiative (similar to test262)?

Regards,
Alexandre

On 12 déc. 2012, at 19:28, Norbert Lindenberg wrote:

> István has informed me that the Ecma General Assembly today unanimously 
> approved ECMA-402, ECMAScript Internationalization API Specification.
>
> http://ecma-international.org/publications/standards/Ecma-402.htm
>
> Norbert
>
>



Alexandre Morgaut
Wakanda Community Manager

4D SAS
60, rue d'Alsace
92110 Clichy
France

Standard : +33 1 40 87 92 00
Email :alexandre.morg...@4d.com
Web :  www.4D.com


___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Creating a filled array with a given length?

[Jussi Kalliokoski]

On Wed, Dec 12, 2012 at 6:08 PM, Rick Waldron wrote:

>
>
>
> On Wed, Dec 12, 2012 at 1:59 AM, Axel Rauschmayer wrote:
>
>> I would still love to have something like that in ES6 (loosely similar to
>> String.prototype.repeat). Once you have that, you can e.g. use
>> Array.prototype.map to do more things.
>>
>> Two possibilities:
>> - Array.repeat(undefined, 3) -> [ undefined, undefined, undefined ]
>> - [ undefined ].repeat(3) -> [ undefined, undefined, undefined ]
>>
>> The same array could be created like this, but that seems too much work
>> for a relatively common operation.
>>
>> 'x'.repeat(3).split('').map(=> undefined)
>>
>
> Array Comprehensions!
>
> This is probably wrong, so treat it more like an idea and less like a
> matter of fact:
>
> [ undefined for x of new Array(3) ].map( v => ... );
>
> [ undefined for x of [0,0,0] ].map( v => ... );
>

This should work, too (at least it works in Firefox, if you use a normal
function):

var powersOfTwo = [ ...Array(8) ].map( (v, i) => 1 << i )

Cheers,
Jussi


> Rick
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: A DOM use case that can't be emulated with direct proxies

[David Bruant]

Le 13/12/2012 00:51, Mark S. Miller a écrit :

On Wed, Dec 12, 2012 at 11:19 AM, David Bruant  wrote:
[...]

* change the behavior of WindowProxy instances when it comes to doing things
that would commit them to eternal invariants to throw instead of forwarding.
This solution may still be possible, because it's unlikely that
Object.defineProperty is widely used in web content today. But this change
should happen pretty fast before content relies on it.

I think this is the only viable solution.
Ok. What do you think of the idea of different handlers based on 
context? [1]



The current behavior violates ES5 in an unintended way[1].

Just to clarify, invariants described in ES5.1 - 8.6.2 are violated.


As you say, to remain viable, it
must be done quickly. From previous experience, I suggest that there's
exactly one way to get quick universal deployment: add a test to
test262 that fails when a browser's WindowProxy object violates this
normative part of the ES5 spec.
I feel such a test would rather belong to the HTML DOM. But either way, 
I agree.
I'll reach out to public-script-coord to re-explain the issue and the 
suggested changes. I'll write a test case, submit it to the webapps 
directory [2] (I'll ask first to be sure it's the right one) and file 
bugs in different browsers.


David

[1] Last point of 
https://mail.mozilla.org/pipermail/es-discuss/2012-December/027092.html

[2] http://dvcs.w3.org/hg/webapps/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss