On 4 June 2014 23:46, John Lenz concavel...@gmail.com wrote:
I don't personally want to write sloppy mode code, but there are places you
need it (using eval to introduce new symbols into global scope).
You don't necessarily need sloppy mode for that. In strict mode, you
can still express it as
On 5 June 2014 16:08, John Barton johnjbar...@google.com wrote:
On Thu, Jun 5, 2014 at 2:06 AM, Andreas Rossberg rossb...@google.com
wrote:
On 4 June 2014 23:46, John Lenz concavel...@gmail.com wrote:
I don't personally want to write sloppy mode code, but there are places
you
need it
Assigning to 'this' because it happens that 'this' is global is no better
and perhaps worse than using undeclared variables for globals. Assignments
to global have, well, non-local consequences: they should be explicit not
context dependent.
Even if you don't agree, node has made global the de
C-style for-loops allow declarations as init statements, but only some
of them. Yet, the others (function and class) are actually
syntactically legal in that position as well, because they are simply
parsed as expressions. Consider:
let x = 0
for (let x = 1; ;) x // 1
for (const x = 1; ;)
On Wed, Jun 4, 2014 at 8:52 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Jun 4, 2014, at 2:43 PM, John Lenz concavel...@gmail.com wrote:
How does someone write code to make sure it doesn't fall into legacy
semantics? Unless, I misunderstand these rules seem like a
Why not accept these as for-loop initializations, so that x actually has
that function and that class as its initial value in the first iteration of
the loop? To me, that's the least surprise. Since this is a position in
which some declarations are accepted, anything there that looks like a
That involves changing the code to use this. But I don't want to derail
the thread here. It is sufficient to say that eval with and
arguments.caller/callee change behavior in strict mode and there is
enough legacy code that need to be dealt with that you can't forcing things
to always be strict
We don't need an identifier for global. Much like with the :: operator in C++,
a member expression starting with a . would always refer to the global object.
So if you want to refer to member foo in the global object, .foo would be
unambiguous.
I feel like it's a simple, yet elegant solution.
Would this still be legal, in this scheme?
for ((function x(){}); ;) x // 0
for ((class x(){}); ;) x // 0
On Thu, Jun 5, 2014 at 7:58 AM, Andreas Rossberg rossb...@google.com
wrote:
C-style for-loops allow declarations as init statements, but only some
of them. Yet, the others
Mark, could you explain how the condition and iteration statements in the
for loop interact with such an initialization? I agree that banning these
seems like the clearer way to go.
On Thu, Jun 5, 2014 at 10:17 AM, Mark S. Miller erig...@google.com wrote:
Why not accept these as for-loop
Consider the function and class declarations in these positions to be
equivalent to:
for (let x = function(){}; ...
and
for (let x = class(){}; ...
respectively.
On Thu, Jun 5, 2014 at 8:32 AM, Will Ray wray...@gmail.com wrote:
Mark, could you explain how the condition and
Hi John, for those it is unsurprising that they would be allowed, and that
they would be taken as expressions rather than declarations.
On Thu, Jun 5, 2014 at 8:23 AM, John Lenz concavel...@gmail.com wrote:
Would this still be legal, in this scheme?
for ((function x(){}); ;) x // 0
for
That is to say, is this valid:
if (x) {
f();
function f() { doSomething() }
}
The same question applies to class declarations. I assume that top level
class declarations hoist. (Where is this in the spec?)
___
es-discuss mailing list
On 5 June 2014 17:44, John Lenz concavel...@gmail.com wrote:
That is to say, is this valid:
if (x) {
f();
function f() { doSomething() }
}
The same question applies to class declarations. I assume that top level
class declarations hoist. (Where is this in the spec?)
Yes, that is
On 5 June 2014 17:17, Mark S. Miller erig...@google.com wrote:
Why not accept these as for-loop initializations, so that x actually has
that function and that class as its initial value in the first iteration of
the loop? To me, that's the least surprise. Since this is a position in
which some
On Jun 5, 2014, at 8:14 AM, John Lenz concavel...@gmail.com wrote:
On Wed, Jun 4, 2014 at 8:52 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
We don’t want to leave the meaning of function declarations in blocks
completely unspecified, as in ES1-5 as we; know there are legacy
Over and beyond the breaking change WRT function, I really don’t see the value
in such a restriction. There are many pointless or nonsensial things that can
be written as expressions. In general, we don’t complicate the language to
make such things illegal.
Allen
On Jun 5, 2014, at 7:58
Is there any place that has some concrete examples of the different cases
we are trying support with this section (and whether the function is block
scoped or not in each case)?
On Thu, Jun 5, 2014 at 9:45 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Jun 5, 2014, at 8:14 AM, John
Having this be legal as an expression makes the language more complex from
the programmer's perspective than either
* prohibiting this, by allowing only expression-statements as expressions
here, or
* accepting any declaration in this position.
I would be surprised if the status quo were simpler
On 5 June 2014 18:50, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Over and beyond the breaking change WRT function, I really don’t see the
value in such a restriction. There are many pointless or nonsensial things
that can be written as expressions. In general, we don’t complicate the
Allen Wirfs-Brock wrote:
Over and beyond the breaking change WRT function,
I bet a tasty donut that we cannot make this breaking change, so why
should we fool around with anything similar for class?
/be
___
es-discuss mailing list
Hi,
Will ES6 have a way to know what is the current module path from inside a
module ?
Such a thing could be useful to locate relative resources, just like node's
__dirname global.
--
Maël Nison (arcanis https://twitter.com/arcanis)
Frontend Developer @ Sketchfab
Le 5 juin 2014 à 16:58, Andreas Rossberg rossb...@google.com a écrit :
The one caveat is that for function, that would actually be a breaking
change, but is it likely to be a real world one?
Here is a plausible example:
for (function(){ /* ... */ }(); ; )
Today, the
Thanks.
On Thu, Jun 5, 2014 at 8:54 AM, Andreas Rossberg rossb...@google.com
wrote:
On 5 June 2014 17:44, John Lenz concavel...@gmail.com wrote:
That is to say, is this valid:
if (x) {
f();
function f() { doSomething() }
}
The same question applies to class declarations. I
I wrote this blog post about some of the pain points I'm dealing with
and dreams of how ES7 might be able to address them:
http://www.nczonline.net/blog/2014/06/03/my-ecmascript-7-wishlist/
A short overview in lieu of posting the whole article here:
* `Array.prototype.first()`,
On Thu, Jun 5, 2014 at 6:42 PM, Nicholas C. Zakas
standa...@nczconsulting.com wrote:
I wrote this blog post about some of the pain points I'm dealing with and
dreams of how ES7 might be able to address them:
http://www.nczonline.net/blog/2014/06/03/my-ecmascript-7-wishlist/
A short
It’d be nice to have a built-in way for comparing numbers, e.g. when sorting
arrays.
```js
// Compact ECMAScript 6 solution
// Risk: number overflow
[1, 5, 3, 12, 2].sort((a,b) = a-b)
// Proposed new function:
[1, 5, 3, 12, 2].sort(Number.compare)
```
--
Dr. Axel Rauschmayer
a...@rauschma.de
On Thu, Jun 5, 2014 at 7:15 PM, Axel Rauschmayer a...@rauschma.de wrote:
```js
// Compact ECMAScript 6 solution
// Risk: number overflow
[1, 5, 3, 12, 2].sort((a,b) = a-b)
```
Is this really an issue for IEEE floating point?
--scott
___
es-discuss
* `Function.empty` - a standard empty function that can be used when you just
want an empty function (IMHO, it indicates intent much better than other
options toda).
Ironically, that’s what Function.prototype is. But using that object in that
capacity is beyond confusing. I’d prefer a
Rick Waldron wrote:
* `Object.preventUndeclaredGet()` - change an object's behavior to
throw an error if you try to read from a property that doesn't
exist (instead of returning `undefine`).
This can be achieved with Proxy right, or is that too cumbersome?
js var NoSuchProperty
On Jun 5, 2014, at 5:52 PM, Brendan Eich bren...@mozilla.org wrote:
Rick Waldron wrote:
* `Object.preventUndeclaredGet()` - change an object's behavior to throw an
error if you try to read from a property that doesn't exist (instead of
returning `undefine`).
This can be achieved with
LOL - as if O.p has getters!
Thanks, this is more general in case of insanity.
/be
On Jun 5, 2014, at 6:09 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Jun 5, 2014, at 5:52 PM, Brendan Eich bren...@mozilla.org wrote:
Rick Waldron wrote:
* `Object.preventUndeclaredGet()` -
On Jun 5, 2014, at 6:25 PM, Brendan Eich bren...@mozilla.org wrote:
LOL - as if O.p has getters!
Thanks, this is more general in case of insanity.
It probably always a good idea to use Reflect.* calls inside of proxy handlers.
I’m seen variants of this mistake in many handlers snippets
33 matches
Mail list logo
