Re: Putting `global` reference in specs

[Brendan Eich]

We cannot introduce a global property named `global` at this point.

I don't think everyone replying lately has read the whole thread 
carefully :-|.


/be

Andrea Giammarchi wrote:
Sure workers too, but it doesn't in server side and it doesn't mean 
anything meaningful for all developers coming from other languages. 
`self` is a misleading word and in ES6 specs we have mentioned global 
object and never a single word for the `self` keyword, or its meaning.


`global` does not need that kind of explanation you put down for 
historical purpose, `global` is well known meaning for everyone in JS 
world, including members in this ML that would refer to the global 
scope, and the global object, regardless they mean sometimes `realm` 
... or isn't it?


On Fri, Apr 17, 2015 at 10:38 PM, Brendan Eich > wrote:


The principle extends just fine to workers, and has.

/be


Andrea Giammarchi wrote:

And that's indeed the only place on Web world where `self`
makes sense:



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

Re: Putting `global` reference in specs

[Brendan Eich]

Jordan Harband wrote:
Is there some reason that a Reflect function (or accessor, but I'd 
prefer a function for ES3 engine support) wouldn't be an option?


Upthread: 
https://esdiscuss.org/topic/putting-global-reference-in-specs#content-16


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

Re: Putting `global` reference in specs

[Andrea Giammarchi]

Sure workers too, but it doesn't in server side and it doesn't mean
anything meaningful for all developers coming from other languages. `self`
is a misleading word and in ES6 specs we have mentioned global object and
never a single word for the `self` keyword, or its meaning.

`global` does not need that kind of explanation you put down for historical
purpose, `global` is well known meaning for everyone in JS world, including
members in this ML that would refer to the global scope, and the global
object, regardless they mean sometimes `realm` ... or isn't it?

On Fri, Apr 17, 2015 at 10:38 PM, Brendan Eich  wrote:

> The principle extends just fine to workers, and has.
>
> /be
>
>
> Andrea Giammarchi wrote:
>
>> And that's indeed the only place on Web world where `self` makes sense:
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Putting `global` reference in specs

[Jordan Harband]

I was under the impression there'd been some interest in a
`Reflect.global()` as a uniform method of providing the global object, or a
proxy to one, in all engines. That would be something that's easily
polyfilled back as far as we like, would allow most code that currently
relies on indirect eval to work in a CSP environment (including the
es6-shim), and would not impose any new global variables, nor any
restrictions on global variables, on existing engines.

Is there some reason that a Reflect function (or accessor, but I'd prefer a
function for ES3 engine support) wouldn't be an option?

On Fri, Apr 17, 2015 at 2:38 PM, Brendan Eich  wrote:

> The principle extends just fine to workers, and has.
>
> /be
>
> Andrea Giammarchi wrote:
>
>> And that's indeed the only place on Web world where `self` makes sense:
>>
> ___
> 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: Putting `global` reference in specs

[Brendan Eich]

The principle extends just fine to workers, and has.

/be

Andrea Giammarchi wrote:

And that's indeed the only place on Web world where `self` makes sense:

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

Re: Putting `global` reference in specs

[Andrea Giammarchi]

And that's indeed the only place on Web world where `self` makes sense:
it's referring to the frame (scoped) context its running, not to the `top`
(global) tab wrapper.



On Fri, Apr 17, 2015 at 7:51 PM, Brendan Eich  wrote:

> Just for historians who might not know, when I did ur-JS in 1995, I made
> multiple names for the global, in part because event handlers (which
> prefigured nested functions in general, and added with-like DOM object
> scoping -- a regret); but also in part because  was a
> thing in Netscape 2.
>
> /be
>
>
> Boris Zbarsky wrote:
>
>> On 4/17/15 10:55 AM, Andrea Giammarchi wrote:
>>
>>> We have `window` in DOM land, `self` in Workers
>>>
>>
>> We have `self` in DOM land too, so you can consistently use `self` across
>> Window and Workers.
>>
>>  and `global` in most common server side JS engines
>>>
>>
>> Sounds like they should add `self`.  ;)
>>
>> -Boris
>> ___
>> 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
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Putting `global` reference in specs

[Brendan Eich]

Just for historians who might not know, when I did ur-JS in 1995, I made 
multiple names for the global, in part because event handlers (which 
prefigured nested functions in general, and added with-like DOM object 
scoping -- a regret); but also in part because  was a 
thing in Netscape 2.


/be

Boris Zbarsky wrote:

On 4/17/15 10:55 AM, Andrea Giammarchi wrote:

We have `window` in DOM land, `self` in Workers


We have `self` in DOM land too, so you can consistently use `self` 
across Window and Workers.



and `global` in most common server side JS engines


Sounds like they should add `self`.  ;)

-Boris
___
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: Putting `global` reference in specs

[Calvin Metcalf]

This came up in iojs, did not go over well.
https://github.com/iojs/io.js/issues/1043

On Fri, Apr 17, 2015 at 1:11 PM Domenic Denicola  wrote:

> One thing I'm surprised nobody has brought up yet is that "global" would
> be an incorrect name in the case of browsers. The actual global object is
> not (and must never be) directly accessible. Instead you get a window proxy
> when you use `window`, `self`, `this`, etc.
>
> As such I think our best bet is for server-side JS runtimes to use `self`
> or `window`.
>
> The latter isn't as crazy as it sounds: just start adding phrases to the
> ES spec like "all JavaScript code runs within a certain context, called a
> _window_, which has a corresponding _window object_. In some runtimes the
> window object will be equivalent to the global object, but not always.
> Scripts run within _window scope_, whereas modules run in their own lexical
> context. The value of **this** in window scope is the window object."
>
> It's not as if `window` actually means "window" anymore, given tabs and
> iframes and frames. We might as well move it into the set of terms like
> "realm" or "vat" or "environment" that are more abstract than real.
>
> -Original Message-
> From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
> Anne van Kesteren
> Sent: Friday, April 17, 2015 11:19
> To: Andrea Giammarchi
> Cc: es-discuss@mozilla.org
> Subject: Re: Putting `global` reference in specs
>
> On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
> > So I'd say we should not have `self` (if stays on global and Worker I
> > don't actually care) and add a `global` that nobody needs explanation
> > to understand what it is in JavaScript
>
> Indeed, three ways to reference the global object is not nearly enough.
>
>
> --
> https://annevankesteren.nl/
> ___
> 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
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Template strings flags

[Axel Rauschmayer]

> Why not provide special formatting flags for `Template strings`?
>  
> Tagged template strings are your friend.

If you want to modify behavior (e.g. cut off prefixed whitespace) then more 
trickery is needed, e.g.:

```js
dedent(String.raw)`…`
```

And there is no handler function that provides untagged behavior.

-- 
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de



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

Re: Template strings flags

[Kevin Smith]

> Why not provide special formatting flags for `Template strings`?
>

Tagged template strings are your friend.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Nailing object property order

[Juriy Zaytsev]

fwiw, tests for enumeration order now in compat table —
https://github.com/kangax/compat-table/commit/a267f2233ce3b25dfbee876f4a4786ad85b31049

Results — https://kangax.github.io/compat-table/es6/#own_property_order

-- 
kangax

On Thu, Apr 16, 2015 at 8:37 PM, Brendan Eich  wrote:

> Also, it's too late. Engines are converging, inter-operation pressure
> points in one direction only: greater convergence and standardization.
>
> It's true engines are not converging on the ancient insertion order, and
> that caused some interop stress, but we are over that hump now. See
> https://code.google.com/p/v8/issues/detail?id=164&can=1&q=enumeration&colspec=ID%20Type%20Status%20Priority%20Owner%20Summary%20HW%20OS%20Area%20Stars
> (a long, and long-resolved, V8 issue).
>
> Bergi's frustration is understandable. Leaving things unspecified for too
> long was a failure on our part in tending the spec, or a trade-off (we had
> other things to do ;-). All water under the bridge, but we're not stepping
> back to unspecified behavior. Because engines aren't, because developers do
> not want.
>
> And agree with Mark: POITROAE.
>
> /be
>
> Mark S. Miller wrote:
>
>> Developer productivity > hypothetical minor performance gains.
>>
>> +1 to all steps to make the specified behavior more deterministic,
>> including this one.
>>
>>
>> On Thu, Apr 16, 2015 at 10:07 AM, liorean > lior...@gmail.com>> wrote:
>>
>> I'm very much opposed to locking this down for general objects because
>> it locks the implementation choices for generic objects down. What if
>> the engine backing implementation was, say, some variation of a trie
>> for instance? It cannot really be done today without adding extraneous
>> data into the structure, because lookup in that case happens on a
>> character by character basis, not on a whole string basis, so
>> properties that use common prefixes would always end up adjacent and
>> even if the keys weren't inserted in order by bit patterns into the
>> trie as most implementations do, they would still be grouped by common
>> prefix.
>> --
>> David "liorean" Andersson
>> ___
>> 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
>>
> ___
> 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: Template strings flags

[Axel Rauschmayer]

Alternative: an operator for function composition.

```js
let text = `…` @@ t;
```


> On 17 Apr 2015, at 19:13, monolithed  wrote:
> 
> Why not provide special formatting flags for `Template strings`?
> 
> ```js
> let text = `text text text text text text
> text text text text text text`t;
> ```
> 
> `t` - trim whitespaces
> 
> Expected result:
> 
> ```js
> let text = `text text text text text text text text text text text text`t;
> ```

-- 
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de



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

Re: Please volunteer to maintain the HTML version of the spec

[Boris Zbarsky]

On 4/17/15 1:16 PM, Axel Rauschmayer wrote:

One way of achieving that is by breaking up the
HTML spec into one page per top-level section, but that has
disadvantages, too.


Indeed.  Like the ability to search in it.  As a spec consumer, having 
specs broken up like this makes them much harder to work with.


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

Re: Putting `global` reference in specs

[Andrea Giammarchi]

> As such I think our best bet is for server-side JS runtimes to use `self`
or `window`.

I personally hope that would never happen, and you managed to over-engineer
the simplest alignment requirement I could possibly think of ... indeed ...



> We might as well move it into the set of terms like "realm" or "vat" or
"environment" that are more abstract than real.

a new term like realm will just create more fragmentation =>
https://xkcd.com/927/ + there's no such thing on server side, at least not
the same there is on front end

vat is at least semantic in this case since it means Value-Added Tax ...
but I am back to previous point

environment is confusing with `process.env`



Let's avoid the introduction of more problems please ... I rather leave
things as it is since we are unable to be pragmatic, no matter how straight
forward is the solution.


On Fri, Apr 17, 2015 at 6:11 PM, Domenic Denicola  wrote:

> One thing I'm surprised nobody has brought up yet is that "global" would
> be an incorrect name in the case of browsers. The actual global object is
> not (and must never be) directly accessible. Instead you get a window proxy
> when you use `window`, `self`, `this`, etc.
>
> As such I think our best bet is for server-side JS runtimes to use `self`
> or `window`.
>
> The latter isn't as crazy as it sounds: just start adding phrases to the
> ES spec like "all JavaScript code runs within a certain context, called a
> _window_, which has a corresponding _window object_. In some runtimes the
> window object will be equivalent to the global object, but not always.
> Scripts run within _window scope_, whereas modules run in their own lexical
> context. The value of **this** in window scope is the window object."
>
> It's not as if `window` actually means "window" anymore, given tabs and
> iframes and frames. We might as well move it into the set of terms like
> "realm" or "vat" or "environment" that are more abstract than real.
>
> -Original Message-
> From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
> Anne van Kesteren
> Sent: Friday, April 17, 2015 11:19
> To: Andrea Giammarchi
> Cc: es-discuss@mozilla.org
> Subject: Re: Putting `global` reference in specs
>
> On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
> > So I'd say we should not have `self` (if stays on global and Worker I
> > don't actually care) and add a `global` that nobody needs explanation
> > to understand what it is in JavaScript
>
> Indeed, three ways to reference the global object is not nearly enough.
>
>
> --
> https://annevankesteren.nl/
> ___
> 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: Please volunteer to maintain the HTML version of the spec

[Axel Rauschmayer]

> I could probably come up with a way to include permanent ids in section 
> headings as  Word invisible fields. 
> 
> It would be a little more work for spec. editors (and somewhat bug prone: 
> forgetting to include one, forgetting to change the id when copying a 
> heading, etc) but would eliminate the need to maintain an external map.

That is a great idea! It may make sense to make each top-level section a 
separate namespace then it’s easier to keep IDs unique and there is graceful 
degradation. One way of achieving that is by breaking up the HTML spec into one 
page per top-level section, but that has disadvantages, too.

-- 
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de



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

Template strings flags

[monolithed]

Why not provide special formatting flags for `Template strings`? ```js let
text = `text text text text text text text text text text text text`t; ```
`t` - trim whitespaces Expected result: ```js let text = `text text text
text text text text text text text text text`t; ```


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

RE: Putting `global` reference in specs

[Domenic Denicola]

One thing I'm surprised nobody has brought up yet is that "global" would be an 
incorrect name in the case of browsers. The actual global object is not (and 
must never be) directly accessible. Instead you get a window proxy when you use 
`window`, `self`, `this`, etc.

As such I think our best bet is for server-side JS runtimes to use `self` or 
`window`.

The latter isn't as crazy as it sounds: just start adding phrases to the ES 
spec like "all JavaScript code runs within a certain context, called a 
_window_, which has a corresponding _window object_. In some runtimes the 
window object will be equivalent to the global object, but not always. Scripts 
run within _window scope_, whereas modules run in their own lexical context. 
The value of **this** in window scope is the window object."

It's not as if `window` actually means "window" anymore, given tabs and iframes 
and frames. We might as well move it into the set of terms like "realm" or 
"vat" or "environment" that are more abstract than real.

-Original Message-
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Anne van 
Kesteren
Sent: Friday, April 17, 2015 11:19
To: Andrea Giammarchi
Cc: es-discuss@mozilla.org
Subject: Re: Putting `global` reference in specs

On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi 
 wrote:
> So I'd say we should not have `self` (if stays on global and Worker I 
> don't actually care) and add a `global` that nobody needs explanation 
> to understand what it is in JavaScript

Indeed, three ways to reference the global object is not nearly enough.


--
https://annevankesteren.nl/
___
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: Please volunteer to maintain the HTML version of the spec

[Allen Wirfs-Brock]

On Apr 17, 2015, at 6:20 AM, Jason Orendorff wrote:

> On Thu, Apr 16, 2015 at 3:35 PM, Michael Dyck  wrote:
>> I'm interested.
> 
> OK, thanks. I'll get back to you next week. Unfortunately I'm not around 
> today.

We should probably start by forking your repository and hosting it on 
https://github.com/tc39/ so it can be maintained as part of the official TC39 
tool suite.

The other big thing we need to accomplish in the near future is to have an 
"official" html version that can be released as 
http://www.ecma-international.org/ecma-262/6/index.html   (I may be able to get 
Ecma to change the last node from "6" to "2015")
(See for example  http://www.ecma-international.org/ecma-262/5.1/ and also see 
http://www.ecma-international.org/publications/standards/Ecma-262.htm and 
http://www.ecma-international.org/publications/standards/Ecma-262-arch.htm )

> 
>>> Each time a new revision is published, some manual steps are required
>>> to map broken links to the right sections in the new document.
>> 
>> Do you mean that old 'es6-draft.html' URLs should resolve to the
>> corresponding section in the HTML version of the latest ES7+ draft? (In
>> which case, the latter would need to continue to support (remap) all the old
>> section-ids.) I wonder if people would find that surprising.
> 
> I hadn't considered it.
> 
> Given the use cases I know about (mostly es-discuss and in
> implementations' bug-tracking databases), I think it's better to do it
> the other way, so that ES6-era links continue to point to an ES6 spec.

I agree, also blog post and old tweets, etc...

> 
> Starting from scratch will not save a whole lot of work, though. The
> work required with each revision is mostly figuring out how to
> redirect section-ids that were newly changed in that revision, not
> maintaining the old redirects (which is at most some
> search-and-replace).

I could probably come up with a way to include permanent ids in section 
headings as  Word invisible fields. 

It would be a little more work for spec. editors (and somewhat bug prone: 
forgetting to include one, forgetting to change the id when copying a heading, 
etc) but would eliminate the need to maintain an external map.

Allen

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

Re: Should "const" be favored over "let"?

[Marius Gundersen]

I too have found that most of my variables are defined with const, as they
never change. Let var die is a catchy saying, but I believe it should be
let var die, use const.


On Fri, Apr 17, 2015 at 6:16 PM, Allen Wirfs-Brock 
wrote:

>
> I agree, 'let' is likely to win because of it's length.  I find that I
> fall into using it solely or that reason.  I think it also wins on
> readability.
>
> If we had a "do-over".  I'd make `let` means what `const` now means and
> have something different for defining mutable lexical bindings.  Maybe `let
> var foo=...;`.
>
>
let and mut?  Oh well, too late for that now.

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

Re: Should "const" be favored over "let"?

[Allen Wirfs-Brock]

On Apr 17, 2015, at 5:09 AM, Alex Kocharin wrote:

>  
> There won't be any performance gain. "const" is used to be much slower in v8 
> actually. But they fixed it as far as I know.
>  
> I think it's a code style matter. And speaking about that, realistically, 
> most code base will never use "const" widely. Just one reason: 5 characters 
> vs 3 characters to type. So in the name of keeping an amount of different 
> code styles smaller, I'd say stick with "let" (except for obvious constant 
> literals like `const PI = 3.14` on top). Just something to consider.

I agree, 'let' is likely to win because of it's length.  I find that I fall 
into using it solely or that reason.  I think it also wins on readability. 

If we had a "do-over".  I'd make `let` means what `const` now means and have 
something different for defining mutable lexical bindings.  Maybe `let var 
foo=...;`.

But the let/const pairing was a firmly established direction long before work 
on ES6 even started.  There was so much other stuff to work on and so much 
inertia behind let/const that nobody ever seriously challenged that direction. 

Allen


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

Re: Putting `global` reference in specs

[Andrea Giammarchi]

oh ... that one, it was for Boris who wrote:

> This has the drawback of making eyes bleed, but the benefit of working
reliably (unlike "window", "self", or "global") ;)

I meant that your `eval` wasn't more reliable than window, self, or global,
because ot could have been redefined as well ... but this is not about
shadowability, it's about having one name that fits in every JS situation:
server, worker, document

`global` instead of `window` and/or `self` is a clear win for everyone,
being curse forever to check it `typeof window` or `typeof global` is not
undefined is ... well, the most basic and striking fragmentation case we
have at the root of the language ^_^



On Fri, Apr 17, 2015 at 5:13 PM, Mark S. Miller  wrote:

>
>
> On Fri, Apr 17, 2015 at 9:05 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> I've never said unshadowable ...
>>
>
> You did:
>
> On Fri, Apr 17, 2015 at 8:39 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> also `eval` can be in-scope redefined as much as global, window, or self,
>> so no, that's actually not a solution.
>>
>
>
>
>
>
>
>> I am saying that `global` should be a global reference to the global
>> object which is mentioned in ES6/2015 but it's not specified how it should
>> be referenced. `window` is not welcome even in DOM tools like browserify,
>> `global` is ubiquitous in its meaning, it does not confuse anyone like a
>> `self` in node.js or others would do, and it will solve forever the hassle
>> of referencing *by deafault* a global object without needing to eval,
>> Function('return this'), [].sort(), or whatever wizardy you coudl came up
>> to retrieve and/or reference the global object.
>>
>> It's deadly simple: whatever freedom implementors have to put window
>> and/or self in, they MUST put a `global` reference too ... that will make
>> everything else redundant, in the long term, and not vice-versa
>>
>> Is this really that complicated to ship?
>>
>> On Fri, Apr 17, 2015 at 4:42 PM, Mark S. Miller 
>> wrote:
>>
>>>
>>>
>>> On Fri, Apr 17, 2015 at 8:39 AM, Andrea Giammarchi <
>>> andrea.giammar...@gmail.com> wrote:
>>>
 also `eval` can be in-scope redefined as much as global, window, or
 self, so no, that's actually not a solution.

 Btw, I wasn't asking for a workaround, I was proposing to officially
 bring ES 2015 `global` object as language reference in ES7/201X

>>>
>>> In an unshadowable manner? Never gonna happen. Everything that provides
>>> authority must be virtualizable.
>>>
>>>
>>>

 It's a very tiny improvement for every developer benefit ( 8.5 + 14.1
 millions of results in Github for `typeof global` apparently got unnoticed 
 )

 On Fri, Apr 17, 2015 at 4:33 PM, Andrea Giammarchi <
 andrea.giammar...@gmail.com> wrote:

> it's a no-go under CSP so it's as bad as `Function('return this')()`
>
> On Fri, Apr 17, 2015 at 4:29 PM, Boris Zbarsky 
> wrote:
>
>> On 4/17/15 11:27 AM, Mark S. Miller wrote:
>>
>>> (1,eval)('"use strict"; this')
>>>
>>
>> This has the drawback of making eyes bleed, but the benefit of
>> working reliably (unlike "window", "self", or "global") ;)
>>
>> -Boris
>>
>> ___
>> 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


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

Re: Putting `global` reference in specs

[Mark S. Miller]

On Fri, Apr 17, 2015 at 9:05 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> I've never said unshadowable ...
>

You did:

On Fri, Apr 17, 2015 at 8:39 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> also `eval` can be in-scope redefined as much as global, window, or self,
> so no, that's actually not a solution.
>






> I am saying that `global` should be a global reference to the global
> object which is mentioned in ES6/2015 but it's not specified how it should
> be referenced. `window` is not welcome even in DOM tools like browserify,
> `global` is ubiquitous in its meaning, it does not confuse anyone like a
> `self` in node.js or others would do, and it will solve forever the hassle
> of referencing *by deafault* a global object without needing to eval,
> Function('return this'), [].sort(), or whatever wizardy you coudl came up
> to retrieve and/or reference the global object.
>
> It's deadly simple: whatever freedom implementors have to put window
> and/or self in, they MUST put a `global` reference too ... that will make
> everything else redundant, in the long term, and not vice-versa
>
> Is this really that complicated to ship?
>
> On Fri, Apr 17, 2015 at 4:42 PM, Mark S. Miller 
> wrote:
>
>>
>>
>> On Fri, Apr 17, 2015 at 8:39 AM, Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>>> also `eval` can be in-scope redefined as much as global, window, or
>>> self, so no, that's actually not a solution.
>>>
>>> Btw, I wasn't asking for a workaround, I was proposing to officially
>>> bring ES 2015 `global` object as language reference in ES7/201X
>>>
>>
>> In an unshadowable manner? Never gonna happen. Everything that provides
>> authority must be virtualizable.
>>
>>
>>
>>>
>>> It's a very tiny improvement for every developer benefit ( 8.5 + 14.1
>>> millions of results in Github for `typeof global` apparently got unnoticed )
>>>
>>> On Fri, Apr 17, 2015 at 4:33 PM, Andrea Giammarchi <
>>> andrea.giammar...@gmail.com> wrote:
>>>
 it's a no-go under CSP so it's as bad as `Function('return this')()`

 On Fri, Apr 17, 2015 at 4:29 PM, Boris Zbarsky 
 wrote:

> On 4/17/15 11:27 AM, Mark S. Miller wrote:
>
>> (1,eval)('"use strict"; this')
>>
>
> This has the drawback of making eyes bleed, but the benefit of working
> reliably (unlike "window", "self", or "global") ;)
>
> -Boris
>
> ___
> 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
>>>
>>>
>>
>>
>> --
>> Cheers,
>> --MarkM
>>
>
>


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

Re: Putting `global` reference in specs

[Mark S. Miller]

Yes, something like that is quite plausible. Note though the difference.
Promise is an authority-free safe thing stdized as a global primordial by
the ES spec, with a behavior spec'ed by the ES spec. Although one might
still wish to virtualize it, the reasons are very different.



On Fri, Apr 17, 2015 at 9:06 AM, Jonathan Bond-Caron <
jbo...@gdesolutions.com> wrote:

>  Not so pretty but:
>
> import * as global from “@global”;
>
>
>
> Or some bindings:
>
> import {Promise} from “@global”;
>
>
>
>
>
> *From:* es-discuss [mailto:es-discuss-boun...@mozilla.org] *On Behalf Of *Mark
> Miller
> *Sent:* April 17, 2015 11:53 AM
> *To:* Glen Huang
> *Cc:* Mark S. Miller; es-discuss@mozilla.org
> *Subject:* Re: Putting `global` reference in specs
>
>
>
> This is one of several cases where, post ES6, we can provide a std module
> import that provides a built-in that carries authority. Another example is
> the constructor for making weak references, which necessarily provide the
> ability to read a covert channel. As with shadowable globals, this module
> import must be easy to virtualize. We purposely postponed this along with
> the Loader and Realm API as it is security sensitive and we don't yet have
> enough usage experience with modules to know how to design this separation
> well.
>
>
>
> In particular, we rejected the obvious Reflect.global as it bundles the
> global together with authority-free safe things, which makes virtualization
> of the global alone needlessly unpleasant.
>
>
>
>
>
>
>
> On Fri, Apr 17, 2015 at 8:45 AM, Glen Huang  wrote:
>
>  You guys are talking about referencing the global object in modules
> right? Since in scripts you can reliably get hold of the global object by
> using "this" in the root scope.
>
>
>
> And es 2015 made an explicit choice to clobber "this" in the root scope of
> a module, I guess that means module code really isn't supposed to get hold
> of the global object?
>
>
>
>  On Apr 17, 2015, at 11:34 PM, Mark S. Miller  wrote:
>
>
>
> I almost omitted it, but one should never need to encounter or think about
> sloppy code unless absolutely necessary. For my brain, adding the "use
> strict"; makes this snippet of code much simpler.
>
>
>
>
>
> On Fri, Apr 17, 2015 at 8:30 AM, Andreas Rossberg  > wrote:
>
>   On 17 April 2015 at 17:27, Mark S. Miller  wrote:
>
>  (1,eval)('"use strict"; this')
>
>
>
> Is the 'use strict' relevant here? Seems overkill.
>
>
>
> /Andreas
>
>
>
>
>
>
>
> On Fri, Apr 17, 2015 at 8:23 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>   there's actually no way, officially, to reference what ES2015 call *the
> global object*, just pointless fragmentation between engines.
>
>
>
>
>
>
>
> On Fri, Apr 17, 2015 at 4:19 PM, Anne van Kesteren  > wrote:
>
> On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi
>  wrote:
> > So I'd say we should not have `self` (if stays on global and Worker I
> don't
> > actually care) and add a `global` that nobody needs explanation to
> > understand what it is in JavaScript
>
> Indeed, three ways to reference the global object is not nearly enough.
>
>
> --
> https://annevankesteren.nl/
>
>
>
>
>
> ___
> 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
>
>
>
>
>
>
>
> --
>
> 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
>
>
>
>
>
> --
>
> Text by me above is hereby placed in the public domain
>
>   Cheers,
>   --MarkM
>



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

RE: Putting `global` reference in specs

[Jonathan Bond-Caron]

Not so pretty but:
import * as global from “@global”;

Or some bindings:
import {Promise} from “@global”;


From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Mark 
Miller
Sent: April 17, 2015 11:53 AM
To: Glen Huang
Cc: Mark S. Miller; es-discuss@mozilla.org
Subject: Re: Putting `global` reference in specs

This is one of several cases where, post ES6, we can provide a std module 
import that provides a built-in that carries authority. Another example is the 
constructor for making weak references, which necessarily provide the ability 
to read a covert channel. As with shadowable globals, this module import must 
be easy to virtualize. We purposely postponed this along with the Loader and 
Realm API as it is security sensitive and we don't yet have enough usage 
experience with modules to know how to design this separation well.

In particular, we rejected the obvious Reflect.global as it bundles the global 
together with authority-free safe things, which makes virtualization of the 
global alone needlessly unpleasant.



On Fri, Apr 17, 2015 at 8:45 AM, Glen Huang 
mailto:curvedm...@gmail.com>> wrote:
You guys are talking about referencing the global object in modules right? 
Since in scripts you can reliably get hold of the global object by using "this" 
in the root scope.

And es 2015 made an explicit choice to clobber "this" in the root scope of a 
module, I guess that means module code really isn't supposed to get hold of the 
global object?

On Apr 17, 2015, at 11:34 PM, Mark S. Miller 
mailto:erig...@google.com>> wrote:

I almost omitted it, but one should never need to encounter or think about 
sloppy code unless absolutely necessary. For my brain, adding the "use strict"; 
makes this snippet of code much simpler.


On Fri, Apr 17, 2015 at 8:30 AM, Andreas Rossberg 
mailto:rossb...@google.com>> wrote:
On 17 April 2015 at 17:27, Mark S. Miller 
mailto:erig...@google.com>> wrote:
(1,eval)('"use strict"; this')

Is the 'use strict' relevant here? Seems overkill.

/Andreas



On Fri, Apr 17, 2015 at 8:23 AM, Andrea Giammarchi 
mailto:andrea.giammar...@gmail.com>> wrote:
there's actually no way, officially, to reference what ES2015 call *the global 
object*, just pointless fragmentation between engines.



On Fri, Apr 17, 2015 at 4:19 PM, Anne van Kesteren 
mailto:ann...@annevk.nl>> wrote:
On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi
mailto:andrea.giammar...@gmail.com>> wrote:
> So I'd say we should not have `self` (if stays on global and Worker I don't
> actually care) and add a `global` that nobody needs explanation to
> understand what it is in JavaScript

Indeed, three ways to reference the global object is not nearly enough.


--
https://annevankesteren.nl/


___
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




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



--
Text by me above is hereby placed in the public domain

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

Re: Putting `global` reference in specs

[Andrea Giammarchi]

I've never said unshadowable ... I am saying that `global` should be a
global reference to the global object which is mentioned in ES6/2015 but
it's not specified how it should be referenced. `window` is not welcome
even in DOM tools like browserify, `global` is ubiquitous in its meaning,
it does not confuse anyone like a `self` in node.js or others would do, and
it will solve forever the hassle of referencing *by deafault* a global
object without needing to eval, Function('return this'), [].sort(), or
whatever wizardy you coudl came up to retrieve and/or reference the global
object.

It's deadly simple: whatever freedom implementors have to put window and/or
self in, they MUST put a `global` reference too ... that will make
everything else redundant, in the long term, and not vice-versa

Is this really that complicated to ship?

On Fri, Apr 17, 2015 at 4:42 PM, Mark S. Miller  wrote:

>
>
> On Fri, Apr 17, 2015 at 8:39 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> also `eval` can be in-scope redefined as much as global, window, or self,
>> so no, that's actually not a solution.
>>
>> Btw, I wasn't asking for a workaround, I was proposing to officially
>> bring ES 2015 `global` object as language reference in ES7/201X
>>
>
> In an unshadowable manner? Never gonna happen. Everything that provides
> authority must be virtualizable.
>
>
>
>>
>> It's a very tiny improvement for every developer benefit ( 8.5 + 14.1
>> millions of results in Github for `typeof global` apparently got unnoticed )
>>
>> On Fri, Apr 17, 2015 at 4:33 PM, Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>>> it's a no-go under CSP so it's as bad as `Function('return this')()`
>>>
>>> On Fri, Apr 17, 2015 at 4:29 PM, Boris Zbarsky  wrote:
>>>
 On 4/17/15 11:27 AM, Mark S. Miller wrote:

> (1,eval)('"use strict"; this')
>

 This has the drawback of making eyes bleed, but the benefit of working
 reliably (unlike "window", "self", or "global") ;)

 -Boris

 ___
 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
>>
>>
>
>
> --
> Cheers,
> --MarkM
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Putting `global` reference in specs

[Mark S. Miller]

Which would have made virtualization without translation impossible. Glad
we dodged that bullet ;).


On Fri, Apr 17, 2015 at 9:00 AM, Mameri, Fred (HBO) 
wrote:

>  At some point in the past, I proposed that we introduce syntax for that.
> In my proposal, prefixing an identifier with a "." would create an
> unambiguous reference to the global version of that variable.
>
>  For example:
> ```js
> var x;
> function f(x) {
>x; // local
>.x; // global
> }
> ```
>
>  This is an idea I borrowed from C++’s :: operator.
>
>   From: Mark Miller 
> Date: Friday, April 17, 2015 at 8:53 AM
> To: Glen Huang 
> Cc: "Mark S. Miller" , "es-discuss@mozilla.org" <
> es-discuss@mozilla.org>
> Subject: Re: Putting `global` reference in specs
>
>   This is one of several cases where, post ES6, we can provide a std
> module import that provides a built-in that carries authority. Another
> example is the constructor for making weak references, which necessarily
> provide the ability to read a covert channel. As with shadowable globals,
> this module import must be easy to virtualize. We purposely postponed this
> along with the Loader and Realm API as it is security sensitive and we
> don't yet have enough usage experience with modules to know how to design
> this separation well.
>
>  In particular, we rejected the obvious Reflect.global as it bundles the
> global together with authority-free safe things, which makes virtualization
> of the global alone needlessly unpleasant.
>
>
>
> On Fri, Apr 17, 2015 at 8:45 AM, Glen Huang  wrote:
>
>> You guys are talking about referencing the global object in modules
>> right? Since in scripts you can reliably get hold of the global object by
>> using "this" in the root scope.
>>
>>  And es 2015 made an explicit choice to clobber "this" in the root scope
>> of a module, I guess that means module code really isn't supposed to get
>> hold of the global object?
>>
>>  On Apr 17, 2015, at 11:34 PM, Mark S. Miller  wrote:
>>
>>  I almost omitted it, but one should never need to encounter or think
>> about sloppy code unless absolutely necessary. For my brain, adding the
>> "use strict"; makes this snippet of code much simpler.
>>
>>
>> On Fri, Apr 17, 2015 at 8:30 AM, Andreas Rossberg 
>> wrote:
>>
>>>  On 17 April 2015 at 17:27, Mark S. Miller  wrote:
>>>
 (1,eval)('"use strict"; this')

>>>
>>>  Is the 'use strict' relevant here? Seems overkill.
>>>
>>>  /Andreas
>>>
>>>
>>>

  On Fri, Apr 17, 2015 at 8:23 AM, Andrea Giammarchi <
 andrea.giammar...@gmail.com> wrote:

>  there's actually no way, officially, to reference what ES2015 call
> *the global object*, just pointless fragmentation between engines.
>
>
>
> On Fri, Apr 17, 2015 at 4:19 PM, Anne van Kesteren 
> wrote:
>
>> On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi
>>  wrote:
>> > So I'd say we should not have `self` (if stays on global and Worker
>> I don't
>> > actually care) and add a `global` that nobody needs explanation to
>> > understand what it is in JavaScript
>>
>> Indeed, three ways to reference the global object is not nearly
>> enough.
>>
>>
>> --
>> https://annevankesteren.nl/
>>
>
>
>  ___
> 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


>>>
>>
>>
>>  --
>> 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
>>
>>
>
>
>  --
> Text by me above is hereby placed in the public domain
>
>   Cheers,
>   --MarkM
>
> -
> This e-mail is intended only for the use of the addressees. Any copying,
> forwarding, printing or other use of this e-mail by persons other than the
> addressees is not authorized. This e-mail may contain information that is
> privileged, confidential and exempt from disclosure. If you are not the
> intended recipient, please notify us immediately by return e-mail
> (including the original message in your reply) and then delete and discard
> all copies of the e-mail.
>
> Thank you.
>
> -
>



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

Re: Putting `global` reference in specs

[Mark Miller]

This is one of several cases where, post ES6, we can provide a std module
import that provides a built-in that carries authority. Another example is
the constructor for making weak references, which necessarily provide the
ability to read a covert channel. As with shadowable globals, this module
import must be easy to virtualize. We purposely postponed this along with
the Loader and Realm API as it is security sensitive and we don't yet have
enough usage experience with modules to know how to design this separation
well.

In particular, we rejected the obvious Reflect.global as it bundles the
global together with authority-free safe things, which makes virtualization
of the global alone needlessly unpleasant.



On Fri, Apr 17, 2015 at 8:45 AM, Glen Huang  wrote:

> You guys are talking about referencing the global object in modules right?
> Since in scripts you can reliably get hold of the global object by using
> "this" in the root scope.
>
> And es 2015 made an explicit choice to clobber "this" in the root scope of
> a module, I guess that means module code really isn't supposed to get hold
> of the global object?
>
> On Apr 17, 2015, at 11:34 PM, Mark S. Miller  wrote:
>
> I almost omitted it, but one should never need to encounter or think about
> sloppy code unless absolutely necessary. For my brain, adding the "use
> strict"; makes this snippet of code much simpler.
>
>
> On Fri, Apr 17, 2015 at 8:30 AM, Andreas Rossberg 
> wrote:
>
>> On 17 April 2015 at 17:27, Mark S. Miller  wrote:
>>
>>> (1,eval)('"use strict"; this')
>>>
>>
>> Is the 'use strict' relevant here? Seems overkill.
>>
>> /Andreas
>>
>>
>>
>>>
>>> On Fri, Apr 17, 2015 at 8:23 AM, Andrea Giammarchi <
>>> andrea.giammar...@gmail.com> wrote:
>>>
 there's actually no way, officially, to reference what ES2015 call *the
 global object*, just pointless fragmentation between engines.



 On Fri, Apr 17, 2015 at 4:19 PM, Anne van Kesteren 
 wrote:

> On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi
>  wrote:
> > So I'd say we should not have `self` (if stays on global and Worker
> I don't
> > actually care) and add a `global` that nobody needs explanation to
> > understand what it is in JavaScript
>
> Indeed, three ways to reference the global object is not nearly enough.
>
>
> --
> https://annevankesteren.nl/
>


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


-- 
Text by me above is hereby placed in the public domain

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

Re: Putting `global` reference in specs

[Mameri, Fred (HBO)]

At some point in the past, I proposed that we introduce syntax for that. In my 
proposal, prefixing an identifier with a "." would create an unambiguous 
reference to the global version of that variable.

For example:
```js
var x;
function f(x) {
   x; // local
   .x; // global
}
```

This is an idea I borrowed from C++'s :: operator.

From: Mark Miller mailto:erig...@gmail.com>>
Date: Friday, April 17, 2015 at 8:53 AM
To: Glen Huang mailto:curvedm...@gmail.com>>
Cc: "Mark S. Miller" mailto:erig...@google.com>>, 
"es-discuss@mozilla.org" 
mailto:es-discuss@mozilla.org>>
Subject: Re: Putting `global` reference in specs

This is one of several cases where, post ES6, we can provide a std module 
import that provides a built-in that carries authority. Another example is the 
constructor for making weak references, which necessarily provide the ability 
to read a covert channel. As with shadowable globals, this module import must 
be easy to virtualize. We purposely postponed this along with the Loader and 
Realm API as it is security sensitive and we don't yet have enough usage 
experience with modules to know how to design this separation well.

In particular, we rejected the obvious Reflect.global as it bundles the global 
together with authority-free safe things, which makes virtualization of the 
global alone needlessly unpleasant.



On Fri, Apr 17, 2015 at 8:45 AM, Glen Huang 
mailto:curvedm...@gmail.com>> wrote:
You guys are talking about referencing the global object in modules right? 
Since in scripts you can reliably get hold of the global object by using "this" 
in the root scope.

And es 2015 made an explicit choice to clobber "this" in the root scope of a 
module, I guess that means module code really isn't supposed to get hold of the 
global object?

On Apr 17, 2015, at 11:34 PM, Mark S. Miller 
mailto:erig...@google.com>> wrote:

I almost omitted it, but one should never need to encounter or think about 
sloppy code unless absolutely necessary. For my brain, adding the "use strict"; 
makes this snippet of code much simpler.


On Fri, Apr 17, 2015 at 8:30 AM, Andreas Rossberg 
mailto:rossb...@google.com>> wrote:
On 17 April 2015 at 17:27, Mark S. Miller 
mailto:erig...@google.com>> wrote:
(1,eval)('"use strict"; this')

Is the 'use strict' relevant here? Seems overkill.

/Andreas



On Fri, Apr 17, 2015 at 8:23 AM, Andrea Giammarchi 
mailto:andrea.giammar...@gmail.com>> wrote:
there's actually no way, officially, to reference what ES2015 call *the global 
object*, just pointless fragmentation between engines.



On Fri, Apr 17, 2015 at 4:19 PM, Anne van Kesteren 
mailto:ann...@annevk.nl>> wrote:
On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi
mailto:andrea.giammar...@gmail.com>> wrote:
> So I'd say we should not have `self` (if stays on global and Worker I don't
> actually care) and add a `global` that nobody needs explanation to
> understand what it is in JavaScript

Indeed, three ways to reference the global object is not nearly enough.


--
https://annevankesteren.nl/


___
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





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




--
Text by me above is hereby placed in the public domain

  Cheers,
  --MarkM

-
This e-mail is intended only for the use of the addressees.  Any copying, 
forwarding, printing or other use of this e-mail by persons other than the 
addressees is not authorized.  This e-mail may contain information that is 
privileged, confidential and exempt from disclosure. If you are not the 
intended recipient, please notify us immediately by return e-mail (including 
the original message in your reply) and then delete and discard all copies of 
the e-mail. 

Thank you.

-

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

Re: Putting `global` reference in specs

[Glen Huang]

You guys are talking about referencing the global object in modules right? 
Since in scripts you can reliably get hold of the global object by using "this" 
in the root scope.

And es 2015 made an explicit choice to clobber "this" in the root scope of a 
module, I guess that means module code really isn't supposed to get hold of the 
global object?

> On Apr 17, 2015, at 11:34 PM, Mark S. Miller  wrote:
> 
> I almost omitted it, but one should never need to encounter or think about 
> sloppy code unless absolutely necessary. For my brain, adding the "use 
> strict"; makes this snippet of code much simpler.
> 
> 
> On Fri, Apr 17, 2015 at 8:30 AM, Andreas Rossberg  > wrote:
> On 17 April 2015 at 17:27, Mark S. Miller  > wrote:
> (1,eval)('"use strict"; this')
> 
> Is the 'use strict' relevant here? Seems overkill.
> 
> /Andreas
> 
>  
> 
> On Fri, Apr 17, 2015 at 8:23 AM, Andrea Giammarchi 
> mailto:andrea.giammar...@gmail.com>> wrote:
> there's actually no way, officially, to reference what ES2015 call *the 
> global object*, just pointless fragmentation between engines.
> 
> 
> 
> On Fri, Apr 17, 2015 at 4:19 PM, Anne van Kesteren  > wrote:
> On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi
> mailto:andrea.giammar...@gmail.com>> wrote:
> > So I'd say we should not have `self` (if stays on global and Worker I don't
> > actually care) and add a `global` that nobody needs explanation to
> > understand what it is in JavaScript
> 
> Indeed, three ways to reference the global object is not nearly enough.
> 
> 
> --
> https://annevankesteren.nl/ 
> 
> 
> ___
> 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 
> 
> 
> 
> 
> 
> 
> -- 
> 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: Putting `global` reference in specs

[Alex Kocharin]

 `self` is a very common local variable name, usually used as a substitute of `this`. So making it a global variable is a terrible idea. Consider this: ```function blah() {} blah.prototype.foo = function () {  var self = this   asyncStuff(function () {    self.complete = true  })}``` So what happens if you forget that `var self` declaration? Right now in server-side js it's a good old reference error. But if `self` gets adopted, this code will not always fail, but will lead to mistakes (global variable named `complete` in this example). I'd much rather have "window" and "global" as is honestly.  17.04.2015, 18:02, "Boris Zbarsky" :On 4/17/15 10:55 AM, Andrea Giammarchi wrote: We have `window` in DOM land, `self` in WorkersWe have `self` in DOM land too, so you can consistently use `self` across Window and Workers. and `global` in most common server side JS enginesSounds like they should add `self`.  ;)-Boris___es-discuss mailing listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Putting `global` reference in specs

[Mark S. Miller]

On Fri, Apr 17, 2015 at 8:39 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> also `eval` can be in-scope redefined as much as global, window, or self,
> so no, that's actually not a solution.
>
> Btw, I wasn't asking for a workaround, I was proposing to officially bring
> ES 2015 `global` object as language reference in ES7/201X
>

In an unshadowable manner? Never gonna happen. Everything that provides
authority must be virtualizable.



>
> It's a very tiny improvement for every developer benefit ( 8.5 + 14.1
> millions of results in Github for `typeof global` apparently got unnoticed )
>
> On Fri, Apr 17, 2015 at 4:33 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> it's a no-go under CSP so it's as bad as `Function('return this')()`
>>
>> On Fri, Apr 17, 2015 at 4:29 PM, Boris Zbarsky  wrote:
>>
>>> On 4/17/15 11:27 AM, Mark S. Miller wrote:
>>>
 (1,eval)('"use strict"; this')

>>>
>>> This has the drawback of making eyes bleed, but the benefit of working
>>> reliably (unlike "window", "self", or "global") ;)
>>>
>>> -Boris
>>>
>>> ___
>>> 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
>
>


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

Re: Putting `global` reference in specs

[Mark S. Miller]

On Fri, Apr 17, 2015 at 8:33 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> it's a no-go under CSP so it's as bad as `Function('return this')()`
>

Precisely. Which raises an interesting point. Does anyone know of a
*precise* statement of the actual threat model that CSP's "no eval" is
suppose to protect against?

The reason I ask is that I suspect that there's no valid reason for SES's
"eval", "confine", and "Function" to be disabled by CSP's no-eval mode.
Indeed, SES-with-eval is much safer for most purposes than JS-without-eval.

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

Re: Putting `global` reference in specs

[Andrea Giammarchi]

also `eval` can be in-scope redefined as much as global, window, or self,
so no, that's actually not a solution.

Btw, I wasn't asking for a workaround, I was proposing to officially bring
ES 2015 `global` object as language reference in ES7/201X

It's a very tiny improvement for every developer benefit ( 8.5 + 14.1
millions of results in Github for `typeof global` apparently got unnoticed )

On Fri, Apr 17, 2015 at 4:33 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> it's a no-go under CSP so it's as bad as `Function('return this')()`
>
> On Fri, Apr 17, 2015 at 4:29 PM, Boris Zbarsky  wrote:
>
>> On 4/17/15 11:27 AM, Mark S. Miller wrote:
>>
>>> (1,eval)('"use strict"; this')
>>>
>>
>> This has the drawback of making eyes bleed, but the benefit of working
>> reliably (unlike "window", "self", or "global") ;)
>>
>> -Boris
>>
>> ___
>> 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: do while scope

[Glen Huang]

Thank you.
 
I just post my new understanding a few seconds earlier. Hope that's right. :)

> On Apr 17, 2015, at 11:28 PM, Andreas Rossberg  wrote:
> 
> On 17 April 2015 at 17:18, Glen Huang  > wrote:
> Not sure about others, but i assume the condition part and statement part in 
> a control construct live in the same scope.
> 
> That's why you can do `for (let a = 1; a < 2; a++) a;`. And `if (let a = 1) 
> a;` maybe in es7?
> 
> Why that's not the case for "do while"? Is my mental model wrong?
> 
> Yes. :)
> 
> for (let x ...) scopes over the body naturally. In your example, you expect 
> to scope an inner declaration (one even inside a block) to scope to the 
> outside. That is something else entirely, and makes no sense to me.
> 
> /Andreas
> 
> 
> > On Apr 17, 2015, at 11:10 PM, Caitlin Potter  > > wrote:
> >
> > Is there a language where lexically scoped variables declared in a block 
> > are accessible outside of that block? Java, C, C#, rust, Python, etc, will 
> > not let you do this. I’m not sure this is a gotcha for most software 
> > developers
> >
> >> On Apr 17, 2015, at 10:57 AM, Glen Huang  >> > wrote:
> >>
> >> ```js
> >> do {
> >> let a = 1;
> >> } while (a);
> >> ```
> >> is "a" undefined in the while condition? This seems like a gotcha.
> >>
> >>
> >> ___
> >> 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 
> 
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Putting `global` reference in specs

[Mark S. Miller]

I almost omitted it, but one should never need to encounter or think about
sloppy code unless absolutely necessary. For my brain, adding the "use
strict"; makes this snippet of code much simpler.


On Fri, Apr 17, 2015 at 8:30 AM, Andreas Rossberg 
wrote:

> On 17 April 2015 at 17:27, Mark S. Miller  wrote:
>
>> (1,eval)('"use strict"; this')
>>
>
> Is the 'use strict' relevant here? Seems overkill.
>
> /Andreas
>
>
>
>>
>> On Fri, Apr 17, 2015 at 8:23 AM, Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>>> there's actually no way, officially, to reference what ES2015 call *the
>>> global object*, just pointless fragmentation between engines.
>>>
>>>
>>>
>>> On Fri, Apr 17, 2015 at 4:19 PM, Anne van Kesteren 
>>> wrote:
>>>
 On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi
  wrote:
 > So I'd say we should not have `self` (if stays on global and Worker I
 don't
 > actually care) and add a `global` that nobody needs explanation to
 > understand what it is in JavaScript

 Indeed, three ways to reference the global object is not nearly enough.


 --
 https://annevankesteren.nl/

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


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

Re: Putting `global` reference in specs

[Andrea Giammarchi]

it's a no-go under CSP so it's as bad as `Function('return this')()`

On Fri, Apr 17, 2015 at 4:29 PM, Boris Zbarsky  wrote:

> On 4/17/15 11:27 AM, Mark S. Miller wrote:
>
>> (1,eval)('"use strict"; this')
>>
>
> This has the drawback of making eyes bleed, but the benefit of working
> reliably (unlike "window", "self", or "global") ;)
>
> -Boris
>
> ___
> 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: Putting `global` reference in specs

[Andreas Rossberg]

On 17 April 2015 at 17:27, Mark S. Miller  wrote:

> (1,eval)('"use strict"; this')
>

Is the 'use strict' relevant here? Seems overkill.

/Andreas



>
> On Fri, Apr 17, 2015 at 8:23 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> there's actually no way, officially, to reference what ES2015 call *the
>> global object*, just pointless fragmentation between engines.
>>
>>
>>
>> On Fri, Apr 17, 2015 at 4:19 PM, Anne van Kesteren 
>> wrote:
>>
>>> On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi
>>>  wrote:
>>> > So I'd say we should not have `self` (if stays on global and Worker I
>>> don't
>>> > actually care) and add a `global` that nobody needs explanation to
>>> > understand what it is in JavaScript
>>>
>>> Indeed, three ways to reference the global object is not nearly enough.
>>>
>>>
>>> --
>>> https://annevankesteren.nl/
>>>
>>
>>
>> ___
>> 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
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Putting `global` reference in specs

[Boris Zbarsky]

On 4/17/15 11:27 AM, Mark S. Miller wrote:

(1,eval)('"use strict"; this')


This has the drawback of making eyes bleed, but the benefit of working 
reliably (unlike "window", "self", or "global") ;)


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

Re: do while scope

[Andreas Rossberg]

On 17 April 2015 at 17:18, Glen Huang  wrote:

> Not sure about others, but i assume the condition part and statement part
> in a control construct live in the same scope.
>
> That's why you can do `for (let a = 1; a < 2; a++) a;`. And `if (let a =
> 1) a;` maybe in es7?
>
> Why that's not the case for "do while"? Is my mental model wrong?
>

Yes. :)

for (let x ...) scopes over the body naturally. In your example, you expect
to scope an inner declaration (one even inside a block) to scope to the
outside. That is something else entirely, and makes no sense to me.

/Andreas


> > On Apr 17, 2015, at 11:10 PM, Caitlin Potter 
> wrote:
> >
> > Is there a language where lexically scoped variables declared in a block
> are accessible outside of that block? Java, C, C#, rust, Python, etc, will
> not let you do this. I’m not sure this is a gotcha for most software
> developers
> >
> >> On Apr 17, 2015, at 10:57 AM, Glen Huang  wrote:
> >>
> >> ```js
> >> do {
> >> let a = 1;
> >> } while (a);
> >> ```
> >> is "a" undefined in the while condition? This seems like a gotcha.
> >>
> >>
> >> ___
> >> 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
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: do while scope

[Glen Huang]

Ah, yes, I meant reference error.

I just realized maybe my mental model is wrong:

Is it correct that this is the scope chain for a "for" loop?

top scope
  for condition scope
for statement scope

Statement can reference variables defined in condition, but not the other way 
around?

> On Apr 17, 2015, at 11:15 PM, Caitlin Potter  wrote:
> 
> er, to add to that, “a” shouldn’t be undefined during the while condition, 
> this should throw — it’s a reference error
> 
> 
>> On Apr 17, 2015, at 11:10 AM, Caitlin Potter  wrote:
>> 
>> Is there a language where lexically scoped variables declared in a block are 
>> accessible outside of that block? Java, C, C#, rust, Python, etc, will not 
>> let you do this. I’m not sure this is a gotcha for most software developers
>> 
>>> On Apr 17, 2015, at 10:57 AM, Glen Huang  wrote:
>>> 
>>> ```js
>>> do {
>>> let a = 1;
>>> } while (a);
>>> ```
>>> is "a" undefined in the while condition? This seems like a gotcha.
>>> 
>>> 
>>> ___
>>> 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: Putting `global` reference in specs

[Mark S. Miller]

(1,eval)('"use strict"; this')

On Fri, Apr 17, 2015 at 8:23 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> there's actually no way, officially, to reference what ES2015 call *the
> global object*, just pointless fragmentation between engines.
>
>
>
> On Fri, Apr 17, 2015 at 4:19 PM, Anne van Kesteren 
> wrote:
>
>> On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi
>>  wrote:
>> > So I'd say we should not have `self` (if stays on global and Worker I
>> don't
>> > actually care) and add a `global` that nobody needs explanation to
>> > understand what it is in JavaScript
>>
>> Indeed, three ways to reference the global object is not nearly enough.
>>
>>
>> --
>> https://annevankesteren.nl/
>>
>
>
> ___
> 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: do while scope

[Caitlin Potter]

Well, there's a lot of precedent I'm languages for it (the while condition) to 
not be a part of the block scope. So from that prospective it's unsurprising, 
though it may surprise developers accustomed to variable hosting

> On Apr 17, 2015, at 11:18 AM, Glen Huang  wrote:
> 
> Not sure about others, but i assume the condition part and statement part in 
> a control construct live in the same scope.
> 
> That's why you can do `for (let a = 1; a < 2; a++) a;`. And `if (let a = 1) 
> a;` maybe in es7?
> 
> Why that's not the case for "do while"? Is my mental model wrong?
> 
>> On Apr 17, 2015, at 11:10 PM, Caitlin Potter  wrote:
>> 
>> Is there a language where lexically scoped variables declared in a block are 
>> accessible outside of that block? Java, C, C#, rust, Python, etc, will not 
>> let you do this. I’m not sure this is a gotcha for most software developers
>> 
>>> On Apr 17, 2015, at 10:57 AM, Glen Huang  wrote:
>>> 
>>> ```js
>>> do {
>>> let a = 1;
>>> } while (a);
>>> ```
>>> is "a" undefined in the while condition? This seems like a gotcha.
>>> 
>>> 
>>> ___
>>> 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: Putting `global` reference in specs

[Andrea Giammarchi]

there's actually no way, officially, to reference what ES2015 call *the
global object*, just pointless fragmentation between engines.



On Fri, Apr 17, 2015 at 4:19 PM, Anne van Kesteren  wrote:

> On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi
>  wrote:
> > So I'd say we should not have `self` (if stays on global and Worker I
> don't
> > actually care) and add a `global` that nobody needs explanation to
> > understand what it is in JavaScript
>
> Indeed, three ways to reference the global object is not nearly enough.
>
>
> --
> https://annevankesteren.nl/
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Putting `global` reference in specs

[Anne van Kesteren]

On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi
 wrote:
> So I'd say we should not have `self` (if stays on global and Worker I don't
> actually care) and add a `global` that nobody needs explanation to
> understand what it is in JavaScript

Indeed, three ways to reference the global object is not nearly enough.


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

Re: do while scope

[Glen Huang]

Not sure about others, but i assume the condition part and statement part in a 
control construct live in the same scope.

That's why you can do `for (let a = 1; a < 2; a++) a;`. And `if (let a = 1) a;` 
maybe in es7?

Why that's not the case for "do while"? Is my mental model wrong?

> On Apr 17, 2015, at 11:10 PM, Caitlin Potter  wrote:
> 
> Is there a language where lexically scoped variables declared in a block are 
> accessible outside of that block? Java, C, C#, rust, Python, etc, will not 
> let you do this. I’m not sure this is a gotcha for most software developers
> 
>> On Apr 17, 2015, at 10:57 AM, Glen Huang  wrote:
>> 
>> ```js
>> do {
>> let a = 1;
>> } while (a);
>> ```
>> is "a" undefined in the while condition? This seems like a gotcha.
>> 
>> 
>> ___
>> 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: do while scope

[Caitlin Potter]

er, to add to that, “a” shouldn’t be undefined during the while condition, this 
should throw — it’s a reference error


> On Apr 17, 2015, at 11:10 AM, Caitlin Potter  wrote:
> 
> Is there a language where lexically scoped variables declared in a block are 
> accessible outside of that block? Java, C, C#, rust, Python, etc, will not 
> let you do this. I’m not sure this is a gotcha for most software developers
> 
>> On Apr 17, 2015, at 10:57 AM, Glen Huang  wrote:
>> 
>> ```js
>> do {
>> let a = 1;
>> } while (a);
>> ```
>> is "a" undefined in the while condition? This seems like a gotcha.
>> 
>> 
>> ___
>> 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: Putting `global` reference in specs

[Andrea Giammarchi]

I know that, reason JSLint complains when used internally instead of
`that`, but `self` is the most misleading name ever for whoever comes from
Python and PHP or mostly any other language + self is **nowehere** in
ECMAScript specifications.

So I'd say we should not have `self` (if stays on global and Worker I don't
actually care) and add a `global` that nobody needs explanation to
understand what it is in JavaScript

On Fri, Apr 17, 2015 at 4:02 PM, Boris Zbarsky  wrote:

> On 4/17/15 10:55 AM, Andrea Giammarchi wrote:
>
>> We have `window` in DOM land, `self` in Workers
>>
>
> We have `self` in DOM land too, so you can consistently use `self` across
> Window and Workers.
>
>  and `global` in most common server side JS engines
>>
>
> Sounds like they should add `self`.  ;)
>
> -Boris
> ___
> 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: do while scope

[Caitlin Potter]

Is there a language where lexically scoped variables declared in a block are 
accessible outside of that block? Java, C, C#, rust, Python, etc, will not let 
you do this. I’m not sure this is a gotcha for most software developers

> On Apr 17, 2015, at 10:57 AM, Glen Huang  wrote:
> 
> ```js
> do {
>  let a = 1;
> } while (a);
> ```
> is "a" undefined in the while condition? This seems like a gotcha.
> 
> 
> ___
> 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: forward-incompatible Function.prototype.toString requirement

[Mark S. Miller]

On Fri, Apr 17, 2015 at 7:10 AM, Juriy Zaytsev  wrote:

> I did some research on this just last year —
> http://perfectionkills.com/state-of-function-decompilation-in-javascript/
> (and originally back in 2009, when things were much wilder,
> http://perfectionkills.com/those-tricky-functions/)
>
> Corresponding tests with notes —
> http://kangax.github.io/jstests/function-decompilation/
>
> Cool, thanks. Lots of ancient history there. Of recent versions of
browsers / engines, what problems do you see in arriving at ES6 conformance?

Btw, I was amused to see the old Caja es5-to-es3 transpiler case in there:

function f(){}; // function f() { [cajoled code] }
var f = function(){}; // function f$_var() { [cajoled code] }


which does raise the issue of how transpilers should cope with these
requirements. If the source string produced does parse, what language layer
should it be expressed in?
(Note: Modern Caja uses SES, which usually does not transpile)



> Just few days ago, I've been also thinking to add tests to ES6 compat
> table checking these exact (ES6 introduced) "toString representation
> requirements" from 19.2.3.5.
>

Please do! Beyond ES6 conformance, it looks like we could plausibly stdize
something like the following for the "must not parse" case:

The function head should parse as some kind of function head.
The function body must match /^\s*{\s*\[[^{}\[\]]*\]\s*}\s*$/
i.e.,
{ [ non-"{}[]"-text ] }

The proposal would effectively commit us to never introducing a future
syntax where this parses as a function body, addressing the issue Michael
raises at the beginning of this thread. It would also allow reliable
recognition of those cases intended not to parse for this reason, including
present code recognizing future code (modulo recognizing future function
heads :( ). Does this seem plausible?

Anyone care to write an initial concrete proposal?

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

Re: Putting `global` reference in specs

[Kevin Smith]

>
> We have `self` in DOM land too, so you can consistently use `self`
> across Window and Workers.
>

Why didn't I know this!?  Cool : )

> and `global` in most common server side JS engines
>
> Sounds like they should add `self`.  ;)
>

That would make sense.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Putting `global` reference in specs

[Boris Zbarsky]

On 4/17/15 10:55 AM, Andrea Giammarchi wrote:

We have `window` in DOM land, `self` in Workers


We have `self` in DOM land too, so you can consistently use `self` 
across Window and Workers.



and `global` in most common server side JS engines


Sounds like they should add `self`.  ;)

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

do while scope

[Glen Huang]

```js
do {
  let a = 1;
} while (a);
```
is "a" undefined in the while condition? This seems like a gotcha.


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

Putting `global` reference in specs

[Andrea Giammarchi]

We have `window` in DOM land, `self` in Workers, and `global` in most
common server side JS engines ... plus we have this in ES6 specification:

> In addition to the properties defined in this specification the *global*
object may have additional host defined properties. This may include a
property whose value is the *global* object itself; for example, in
the HTML document object model the window property of the *global* object
is the *global* object itself.

Now, accordingly with this madness:

8.5 millions checks for `typeof global`
https://github.com/search?q=%27typeof+global%27&type=Code&ref=searchresults&utf8=

14.1 millions checks for `typeof window`
https://github.com/search?q=%27typeof+window%27&type=Code&ref=searchresults&utf8=

Does anyone have a concrete reason for NOT specifying **global** as
reference to whatever `window` or `self` reference already?

I've suggested to stick this on top of every wen page:
```html
var global=global||this;
```

and this on top of every Worker
```js
var global=global||this;
```

But I'm pretty sure if ECMAScript would have that in specs we might see the
end of the debate and the infamouse `typeof window` or `typeof global`
check.

Thanks in advance for thoughts
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Final ES6 Draft (Jason Orendorff)

[Benjamin (Inglor) Gruenbaum]

Awesome work! Truly an exciting milestone.

A lot of really nice stuff is in, and the future with ES7 looks bright.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: forward-incompatible Function.prototype.toString requirement

[Juriy Zaytsev]

I did some research on this just last year —
http://perfectionkills.com/state-of-function-decompilation-in-javascript/
(and originally back in 2009, when things were much wilder,
http://perfectionkills.com/those-tricky-functions/)

Corresponding tests with notes —
http://kangax.github.io/jstests/function-decompilation/

Just few days ago, I've been also thinking to add tests to ES6 compat table
checking these exact (ES6 introduced) "toString representation
requirements" from 19.2.3.5.

-- 
kangax

On Thu, Apr 16, 2015 at 4:33 PM, Mark S. Miller  wrote:

> I agree with all this. Let's gather current precedent across JS
> implementations of function printings are not and should not be parseable
> and see if we can extract a clear spec that is consistent enough with
> current reality.
>
>
> On v8:
> > Object
> function Object() { [native code] }
> > Object.bind(Object)
> function () { [native code] }
>
> On SpiderMonkey:
> > Object
> function Object() {
> [native code]
> }
> > Object.bind(Object)
> function Object() {
> [native code]
> }
>
> On JSC:
> > Object
> function Object() {
> [native code]
> }
> > Object.bind(Object)
> function Object() {
> [native code]
> }
>
>
> Looks promising so far! Anyone care to do a more complete investigation
> and write up an initial proposal?
>
>
>
>
> On Thu, Apr 16, 2015 at 7:13 AM, Frankie Bagnardi 
> wrote:
>
>> I just meant that it seems confusing that it can both produce a 
>> FunctionExpression
>> and "return a string for which eval will throw a SyntaxError exception."
>>
>> I didn't mean to highjack this thread; the concern in the original email
>> is noteworthy.  There should be recommended syntaxes which future versions
>> of the spec agree not to break, including current browser implementations.
>> This gives any future engines, or modifications to current engines a
>> clearly defined acceptable way to format these strings.
>>
>> This also gives libraries which parse functions at runtime (despite how
>> good of an idea this is) quick bail cases without using eval.  Examples of
>> this are angular and require.js.
>>
>>
>>
>> On Thu, Apr 16, 2015 at 6:55 AM, Mark S. Miller 
>> wrote:
>>
>>>
>>>
>>> On Thu, Apr 16, 2015 at 6:36 AM, Andreas Rossberg 
>>> wrote:
>>>
 On 16 April 2015 at 14:34, Frankie Bagnardi 
 wrote:

> The part that sticks out to me is... toString on functions currently
> throws a syntax error when eval'd for non-named functions.  Tested in
> chrome:
>
> var f = function(){ return 1 };eval(f.toString()); // SyntaxError
> // becausefunction(){ return 1 }; // SyntaxError
> // but, force an expression: eval("(" + f.toString() + ")") // 
> essentially clones f
>
> ​
> This... is confusing in my opinion.
>

 Yeah, the spec says:

 "The string representation must have the syntax of a
 FunctionDeclaration FunctionExpression, GeneratorDeclaration,
 GeneratorExpression, ClassDeclaration, ClassExpression, ArrowFunction,
 MethodDefinition, or GeneratorMethod depending upon the actual
 characteristics of the object."

 which is weird. First, it doesn't really make sense, because whether
 something originates from a declaration vs expression isn't a
 "characteristic of the object". Second, making it return different
 syntactic classes in different cases is not particularly useful for your
 case.

 But then again, using the result of f.toString as input to eval is A
 REAL BAD IDEA anyway; toString should only be used for diagnostics, not
 programmatically, because that is meaningless in general. So I personally
 don't mind the friction.

>>>
>>> Disagree. The purpose of this change in toString spec from ES5 is
>>> primarily to support pass-by-copy closed functions. The intent was that it
>>> always work to evaluate them as expressions, i.e., with the surrounding
>>> parens.
>>>
>>> http://wiki.ecmascript.org/doku.php?id=harmony:function_to_string
>>> http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#there
>>>
>>>
>>>
>>>

 /Andreas



>
>
> On Thu, Apr 16, 2015 at 2:56 AM, Andreas Rossberg  > wrote:
>
>> On 16 April 2015 at 11:34, Michael Ficarra <
>> mfica...@shapesecurity.com> wrote:
>>
>>> ES2015 section 19.2.3.5 (Function.prototype.toString) places four
>>> restrictions on the output of Function.prototype.toString, one of which 
>>> is
>>>
>>> If the implementation cannot produce a source code string that meets
 these criteria then it must return a string for which *eval* will
 throw a *SyntaxError* exception.

>>>
>>> What is a SyntaxError today may not be a SyntaxError tomorrow. How
>>> can an implementation return a string that will satisfy this 
>>> requirement in
>>> the future when the language has added new syntax? Does the committee 
>>> have
>>> a SyntaxError recom

Re: Are ES6 modules in browsers going to get loaded level-by-level?

[John Barton]

On Thu, Apr 16, 2015 at 11:16 PM, medikoo 
wrote:

> Thanks for clarifications,
>
> Still after reading your comments I have a feeling that providing ES6
> modules to browsers (efficient way) will be much more cumbersome and tricky
> than it is to provide CJS ones now.
>

There is no technological reason to have such a feeling. The design of the
ES6 module system makes creating bundles much easier and with much less
chance of error. All of the imports can be computed from a given root
module without relying on the developer build a list or organizing the
bundle inputs into folders.  This is not true for CJS.

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

Re: Final ES6 Draft

[Erik Arvidsson]

Allen, this could never have happened without you. Thank you for all the
hard work.

On Fri, Apr 17, 2015 at 9:32 AM Jason Orendorff 
wrote:

> Congratulations, everyone, on this milestone, and thanks for your
> work. Looking back all the way to ES5, it's striking just how
> substantial an improvement ES6 is. It'll ultimately affect almost
> every line of JS code I write.
>
> -j
>
> On Thu, Apr 16, 2015 at 6:23 PM, Allen Wirfs-Brock
>  wrote:
> > The final ES6 ECMAScript 2014 specification draft has been completed and
> > submitted to the Ecma GA for their consideration and review prior to
> their
> > June vote to approve it as a standard.
> >
> > The final draft is available at
> >
> http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#final_draft
> >
> > The only significant technical change in this draft is some tweaks to
> > completion value generation within iteration statements.  These tweaks
> > ensure that unroll a loop does not change the resulting completion
> values.
> >
> > Other changes are minor editorial corrections including a few Ecma
> styling
> > conformance issues.
> >
> > It will still be possible to make a few very minor editorial corrections
> > before publishings the standard. So please continue to report any bugs or
> > typos you find to bugs.ecmascript.org.
> >
> > ___
> > 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
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Final ES6 Draft

[Jason Orendorff]

Congratulations, everyone, on this milestone, and thanks for your
work. Looking back all the way to ES5, it's striking just how
substantial an improvement ES6 is. It'll ultimately affect almost
every line of JS code I write.

-j

On Thu, Apr 16, 2015 at 6:23 PM, Allen Wirfs-Brock
 wrote:
> The final ES6 ECMAScript 2014 specification draft has been completed and
> submitted to the Ecma GA for their consideration and review prior to their
> June vote to approve it as a standard.
>
> The final draft is available at
> http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#final_draft
>
> The only significant technical change in this draft is some tweaks to
> completion value generation within iteration statements.  These tweaks
> ensure that unroll a loop does not change the resulting completion values.
>
> Other changes are minor editorial corrections including a few Ecma styling
> conformance issues.
>
> It will still be possible to make a few very minor editorial corrections
> before publishings the standard. So please continue to report any bugs or
> typos you find to bugs.ecmascript.org.
>
> ___
> 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: Should "const" be favored over "let"?

[Andreas Rossberg]

On 17 April 2015 at 14:17, Mathias Bynens  wrote:

> On Fri, Apr 17, 2015 at 7:53 AM, Glen Huang  wrote:
> > I've completely replaced "var" with "let" in my es 2015 code, but I
> noticed most variables I introduced never change.
>
> Note that `const` has nothing to do with the value of a variable
> changing or not. It can still change:
>
> const foo = {};
> foo.bar = 42; // does not throw
>
> `const` indicates the *binding* is constant, i.e. there will be no
> reassignments etc.
>

I have to nitpick on this. In usual nomenclature of programming language
semantics the "value" in question is the _reference_ to the object (for
types with reference semantics), and that does not change. That the object
itself actually can be mutable is a separate property.

The idea that const somehow applies transitively is a specific idiosyncrasy
of low-level languages like C and friends, that make flattening and copying
of mutable objects an implicit part of their semantics. It is not the norm,
and actually rather contorted semantically.

/Andreas


> In my post-ES6 code, I use `const` by default, falling back to `let`
> if I explicitly need rebinding. `var` is for legacy code.
> ___
> 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: Please volunteer to maintain the HTML version of the spec

[Jason Orendorff]

On Thu, Apr 16, 2015 at 3:35 PM, Michael Dyck  wrote:
> I'm interested.

OK, thanks. I'll get back to you next week. Unfortunately I'm not around today.

>> Each time a new revision is published, some manual steps are required
>> to map broken links to the right sections in the new document.
>
> Do you mean that old 'es6-draft.html' URLs should resolve to the
> corresponding section in the HTML version of the latest ES7+ draft? (In
> which case, the latter would need to continue to support (remap) all the old
> section-ids.) I wonder if people would find that surprising.

I hadn't considered it.

Given the use cases I know about (mostly es-discuss and in
implementations' bug-tracking databases), I think it's better to do it
the other way, so that ES6-era links continue to point to an ES6 spec.

Starting from scratch will not save a whole lot of work, though. The
work required with each revision is mostly figuring out how to
redirect section-ids that were newly changed in that revision, not
maintaining the old redirects (which is at most some
search-and-replace).

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

Re: Should "const" be favored over "let"?

[Glen Huang]

@Mathias

Thanks for the clarification. I should use "never rebind".

@Alex @Frankie

You guys are right. There won't be any performance gain since it's already 
statically analyzable.

FWIW, I opened a feature request on eslint concerning this coding style: 
https://github.com/eslint/eslint/issues/2333 
 

> On Apr 17, 2015, at 8:17 PM, Mathias Bynens  wrote:
> 
> On Fri, Apr 17, 2015 at 7:53 AM, Glen Huang  wrote:
>> I've completely replaced "var" with "let" in my es 2015 code, but I noticed 
>> most variables I introduced never change.
> 
> Note that `const` has nothing to do with the value of a variable
> changing or not. It can still change:
> 
>const foo = {};
>foo.bar = 42; // does not throw
> 
> `const` indicates the *binding* is constant, i.e. there will be no
> reassignments etc.
> 
> In my post-ES6 code, I use `const` by default, falling back to `let`
> if I explicitly need rebinding. `var` is for legacy code.

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

Re: Should "const" be favored over "let"?

[Mathias Bynens]

On Fri, Apr 17, 2015 at 7:53 AM, Glen Huang  wrote:
> I've completely replaced "var" with "let" in my es 2015 code, but I noticed 
> most variables I introduced never change.

Note that `const` has nothing to do with the value of a variable
changing or not. It can still change:

const foo = {};
foo.bar = 42; // does not throw

`const` indicates the *binding* is constant, i.e. there will be no
reassignments etc.

In my post-ES6 code, I use `const` by default, falling back to `let`
if I explicitly need rebinding. `var` is for legacy code.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Should "const" be favored over "let"?

[Alex Kocharin]

 There won't be any performance gain. "const" is used to be much slower in v8 actually. But they fixed it as far as I know. I think it's a code style matter. And speaking about that, realistically, most code base will never use "const" widely. Just one reason: 5 characters vs 3 characters to type. So in the name of keeping an amount of different code styles smaller, I'd say stick with "let" (except for obvious constant literals like `const PI = 3.14` on top). Just something to consider. io.js core uses "const" everywhere though.  17.04.2015, 08:53, "Glen Huang" :I've completely replaced "var" with "let" in my es 2015 code, but I noticed most variables I introduced never change.Should I replace them with "const"? Will there be any performance gain for most browsers? If so, should such performance gain be considered micro optimization?___es-discuss mailing listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Are ES6 modules in browsers going to get loaded level-by-level?

[Calvin Metcalf]

Neither node.js/iojs nor nginx. Though nginx supports spdy and there is a
http2 module for node but it isn't compatible with express.

On Fri, Apr 17, 2015, 2:31 AM medikoo 
wrote:

> Thanks for clarifications,
>
> Still after reading your comments I have a feeling that providing ES6
> modules to browsers (efficient way) will be much more cumbersome and tricky
> than it is to provide CJS ones now.
> This may lead to scenario when most of us (for easy serve of bundle), will
> prefer to transpile them into something else, but I hope that won't be the
> case.
>
> Another question raises about server support. People are relying on shared
> (or in cloud) hosting solutions. Do all popular servers (Apache, nginx, or
> http server in node.js) support HTTP/2 already? Is it easy to configure
> them
> to serve es6 modules efficient way?
>
>
>
>
>
> --
> View this message in context:
> http://mozilla.6506.n7.nabble.com/Fwd-Are-ES6-modules-in-browsers-going-to-get-loaded-level-by-level-tp337040p338232.html
> Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
> Nabble.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

Playing with variadric fix point combinators in ES6

[liorean]

I've been playing around with the new syntax for a while, and while
searching for a way to get the familiar applicative order Y combinator
to handle mutually recursive functions hadn't managed to find a
JavaScript example, just Python, Haskell, Scheme, OCaml and of course
pure lambda calculus. So I wrote one, though there is really no
original work involved except for direct transposition. If anyone
wants to program without variables ;) here's a helper for you-

http://lpaste.net/130856 or http://www.es6fiddle.com/i8laijui/
-- 
David "liorean" Andersson
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Should "const" be favored over "let"?

[Frankie Bagnardi]

I've switched to let/const completely.  The gain of using const isn't
performance (you can statically analyze whether any non-global is
potentially assigned to).  The gain from const is that it's very very easy
for a human to statically analyze.

If I see a let binding, I know I need to be a bit more careful with editing
that piece of code.

I originally thought this'd be a terrible idea, but it's been working great
for me.


On Thu, Apr 16, 2015 at 10:53 PM, Glen Huang  wrote:

> I've completely replaced "var" with "let" in my es 2015 code, but I
> noticed most variables I introduced never change.
>
> Should I replace them with "const"? Will there be any performance gain for
> most browsers? If so, should such performance gain be considered micro
> optimization?
> ___
> 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: Final ES6 Draft

[Dmitry Soshnikov]

Thanks Allen!

Dmitry

On Thursday, April 16, 2015, Allen Wirfs-Brock 
wrote:

> The final ES6 ECMAScript 2014 specification draft has been completed and
> submitted to the Ecma GA for their consideration and review prior to their
> June vote to approve it as a standard.
>
> The final draft is available at
> http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#final_draft
>
>
> The only significant technical change in this draft is some tweaks to
> completion value generation within iteration statements.  These tweaks
> ensure that unroll a loop does not change the resulting completion values.
>
> Other changes are minor editorial corrections including a few Ecma styling
> conformance issues.
>
> It will still be possible to make a few very minor editorial corrections
> before publishings the standard. So please continue to report any bugs or
> typos you find to bugs.ecmascript.org.
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Final ES6 Draft

[Andrea Giammarchi]

"The final ES6 ECMAScript 2014 .." aka: *The 2015 ECMAScript Language
Specification*

Did I say already putting a year in the name was confusing? :P

Congratulations Allen and thanks to everyone contributing making this
happens.

Best Regards

P.S. little typo in that page ... "This is the final draft of ECME-262 6h
Edition" ... I believe you meant 6th, not just 6h ;-)



On Fri, Apr 17, 2015 at 12:23 AM, Allen Wirfs-Brock 
wrote:

> The final ES6 ECMAScript 2014 specification draft has been completed and
> submitted to the Ecma GA for their consideration and review prior to their
> June vote to approve it as a standard.
>
> The final draft is available at
> http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#final_draft
>
>
> The only significant technical change in this draft is some tweaks to
> completion value generation within iteration statements.  These tweaks
> ensure that unroll a loop does not change the resulting completion values.
>
> Other changes are minor editorial corrections including a few Ecma styling
> conformance issues.
>
> It will still be possible to make a few very minor editorial corrections
> before publishings the standard. So please continue to report any bugs or
> typos you find to bugs.ecmascript.org.
>
> ___
> 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