Just to wrap this thread up, quoting myself from another thread:
In any case, I won't push my proposal anymore.
But for posterity sake, wanted to make one last comment as to why the various
suggestions for IIFE's and arrow expressions are inappropriate for the task:
they change (hijack)
I agree completely, and I fully apologize. Starting the thread this way was
inappropriate, at least without some mitigating text which I did not think
to add. I like the fact that we are all civil to each other here and try to
keep the environment welcoming and friendly. Please no one
(function (a, b, c) {
}(2))
The main disadvantage of that style over the one I'm advocating for is that it
visually separates the variable declaration (`a`) from its value initialization
(`2`). If there's 5, 10, or more lines of code in between them, it makes it
much harder to figure out
Be aware that the way you utilize 'let' will be a breaking change. In ES5 and
ES6
In addition to the fact that this feature is long since co-existing in FF and
doesn't seem to have broken the web, IIUC, there was already a breaking
change in ES6, with `let` and destructuring:
```js
let[x] =
Apart from complicating the engine and the grammar
I've tried to figure out what complications it introduces. In my imperfect
analysis, it hasn't seemed like much. I've written a transpiler tool[1] that
finds `let (x..) { .. }` occurrences and changes them to `{ let x.. .. }`. It
was pretty
I'd like to ask if there's anyone on TC39 that would be willing to champion a
proposal to add the let-block (let-statement) syntax?
I currently write my block-scoped declarations as:
```js
{ let a = 2, b, c;
// ..
}
```
I do this because I want to be in the habit of always putting my
Neither the base (parent) nor derived (child) class requires a constructor, nor
does the child class require a `super()` call. If you omit either constructor,
an assumed one is present. However, if you *do* declare a constructor in a
derived class, you'll need to call `super()` in it.
So, to
Without the direct feature test API I'm suggesting (or something like it), how
will someone feature test the two new (proposed for ES7) `export` forms, for
example?
https://github.com/leebyron/ecmascript-more-export-from
I'm not strongly opposed to going the `Reflect.parse(..)` route for
I think you could write that like this:
outer = outer.filter(arr =
!arr.some((e, i) =
i 0 arr[i-1] === e));
Yes, you are of course correct. What I was doing in the originally cited code
was illustrating using how `reduce(..)` by its nature supports the adjacency
check,
Um, that's not exactly what reduction is meant for.
There's lots of different ways `reduce(..)` gets used in the wild; I can list
several entirely distinct but common idioms right off the top of my head. Just
because it's not the original intent doesn't mean it's invalid to do so.
To the
What have you been calling the MemberExpression TemplateLiteral and
CallExpression TemplateLiteral forms?
Those are two variations of the Tagged String Literals form.
___
es-discuss mailing list
es-discuss@mozilla.org
The example code isn't very compelling either; something more real-world
would be good
I recently ran across a usage of `reduce(..)` that could have benefitted from
an early return. Figured I'd just drop it here for posterity sake, in case
anything ever comes of this idea.
I had an array of
doesn't yet solve my use cases, although I can't speak for Kyle.
It would not support my use-case. At least, in the sense that it's an
all-or-nothing which is counter to what I'm looking for. It's also going to be
way more processing intensive than just doing an `eval` / `Function` test,
bump.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
What this sub-discussion of CSS `supports(..)` is reinforcing is what I said
earlier: a capability to do feature tests in a direct, efficient, and non-hacky
manner is valuable to some/many uses and use-cases, even with the recognition
that it doesn't have to *perfectly* support all conceivable
It's not that it's imperfect. It's that it's useless in the real world.
It's clear it's useless to you. It's not clear that it's useless to everyone.
In fact, I for one definitely find it useful. No sense in continuing to argue
over subjective opinion.
We can already do shallow testing of
I should stress that while my original proposal (linked earlier in thread)
mentions some of the hard ES6 cases (like TCO), my focus is not on creating
feature tests for ES6. ES6 has sailed. Any feature we could possibly conceive
here is quite unlikely to land in a browser before that browser
That sounds like a horrible future to me.
IMO, this is the only remotely sensible go-forward plan to deal with the new
transpiler-reality we're in.
I for one hope that we're using the actual ES6+ code browser makers are
implementing rather than transpiling around it forever.
Ugh.
A lot of feature detection relies on shallow tests:
However, others need to test that features are properly supported by the
engine. This is because shallow testing does not cover engine quirks.
Of course, shallow tests are often totally sufficient, and I'm trying to have
the most
...using eval or Function is not even an option in CSP constrained
environments
...that's exactly what we'd like to know, if a generic syntax will break or
not.
Furthermore, there are things which are valid syntax which cannot be directly
`eval`'d or `Function`'d, such as `import` and
likely to be engine variances in the future
I hope you just mean like changes that ES7 might make to an ES6 feature. And I
hope those aren't syntactic as much as semantic. :)
If there was a change on syntax, I would assert that should be considered a
new feature with its own new test, even if
Has there been any consideration or discussion for direct support of feature
tests for ES7+ features/syntax? I'm thinking specifically of things which are
difficult or impossible to just simply test for, like via the existence of some
identifier.
I have an idea of what that could look like,
Just for posterity sake, since I got tripped up here…
`import .. from this module` did not make it into ES6. It may come in later, in
that form or some other.
___
es-discuss mailing list
es-discuss@mozilla.org
I think you're referring to the `eval` function?
Actually, I'm referring to proposing something new that would substitute for
having to hack feature tests with `eval`.
These are the initial details of my idea, a `Reflect.supports(..)` method:
If you assign another variable from an imported binding, is that assignment
done as a reference to the binding (aka creating another binding) or via
normal reference-copy/value-copy assignment behavior?
```js
export var a = 42;
export function b() { console.log(orig); };
export function
we are NOT changing the semantic of the assignment expression.
So the result is going to be `42` / `orig`, right? :)
The reason I asked is not because I thought we were changing the semantic of
the assignment expression, but because I wasn't sure if this top-level const
or whatever binding
Regarding the internal server error
Ahh, thanks. Yeah, not only is it confusing to see the edit button, but
especially since clicking it asks you to login to the site as if to verify your
authorization to do such. :)
I guess you'd intended to write export {foo as default} instead of export
From my current understanding (based on other threads), this module:
```js
var foo = 42;
export default foo;
export foo;
foo = 10;
```
When imported:
```js
import foo, * as FOO from coolmodule;
foo; // 10
FOO.default; // 10
FOO.foo; // 10
```
However, I am curious if this binding is 2-way or
Of course in my exports, I meant `export {x}` instead of `export x`, but I
tried to edit my OP and I get internal server error. :)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Thanks, all answers super helpful!
One last clarification:
```js
import foo;
```
This doesn't do any binding does it? AFAICT, it just downloads and runs the
module (if it hasn't already)?
If that's true, what's the use-case here besides preloading a module
performance wise?
are there any other builtins that anybody (Kyle, or otherwise) sees as
problematic to continue with the breaking change
As that book chapter mentions, the only other one I've ever used is
RegExp.prototype (being the default empty match /(?:)/ regular expression). I
have used that only once
you want to freeze everything *.empty
I don't think most of those *need* to be frozen, per se, since they're already
immutable: `Function`, `String`, `Number`, `Boolean`, `RegExp`, … all immutable
themselves. `Array.prototype` is however mutable
(`Array.prototype.push(1,2,3)`), so freezing it
I just remembered that I also do a sort of `Object.empty` in my own code
somewhat frequently, as can be seen here for example:
https://github.com/getify/asynquence/blob/master/asq.src.js#L826
Declaring an empty object: `var ø = Object.create(null)`, and then using that
`ø` as a sort of global
I'm not writing to start or join a debate on the merits of using
`Function.prototype` and `Array.prototype` in the aforementioned ways. I'm
writing to confirm that they are in fact used, not just theoretically made up.
I have been writing about and teaching for several years usage of
Just curious… for RegExp, Date, String and the others that *are* changing to
plain objects… does that mean `Object.prototype.toString.call( .. )` will
return [object Object] on them?
Sorry, I've kinda gotten lost on what the default @@toStringTag behavior is
going to be here.
I'm sorry David, I just have to express a dissenting opinion here. While I
could see that better tooling! would be a positive side-effect of some
syntax suggestions, I think it's a overreaching idea to consider such a main
argument for adding new syntax.
You make a compelling argument of how
I'm sorry David, I just have to express a dissenting opinion here. While I
could see that better tooling! would be a positive side-effect of some
syntax suggestions, I think it's a overreaching idea to consider such a main
argument for adding new syntax.
You make a compelling argument of how
If I was a programmer
looking for something like weak referencing in JS for the first time,
weak is what I'd be searching for.
But if you're actually aware of weakrefs (as I am), and you're searching for
them in JS (as I was), and you see WeakMap (as I did), and you make the
conclusion that
You say and you're searching for them in JS (as I was). Had the
abstraction been called ObjectMap or ObjectRegistry, would you have found
it?
I don't think the API name is the only way someone can discover what they're
looking for. Proper documentation for ObjectMap which said keyrefs are
I too have been confused by the name "weakmap"...partially because the name is misleading, and partially because documentation on it is ambiguous/misleading. Specifically, "weakmap" really means "weakkeymap", because only the key is weak, not the value. But then again, "weakkeymap" would be even
A directive would have the same benefits than use strict which is to not
break existing code in platform that do not support this directive.
It would also have the same limitation that use strict; does, which is
that it doesn't play well with (the quite common pattern of) concat'ing
minified
I intuit that the consequences are less harmful. Strict mode can trigger
some syntax errors or throw runtime errors that wouldn't happen in
non-strict code. Different arithmetic is less likely to cause this kind
of problem.
Sure, it might not cause syntax errors, but it would cause subtle
Is it available for general public members to register for an account to
create strawman proposals for ES?
In particular, I'd like to create two proposals for some future discussion:
1. a n (or c) flag for regexp's, that reverses the default capturing
behavior of ( ) to be non-capturing by
Is it available for general public members to register for an account to
create strawman proposals for ES?
No, it's an Ecma TC39 resource. Ecma needs IPR handoff per its patent
covenant so this can't be a free-for-all, for better or worse.
So if a non-TC39 member wants to create suggestions
So if a non-TC39 member wants to create suggestions and proposals and
ideas for the community to discuss, am I to understand that not only this
list, but also the wiki that this list so frequently references, are not
really intended for that?
I didn't say anything about this list. Discussion
I propose a /n flag for regular expressions, which would swap the default
capturing/non-capturing behavior between ( ) and (?: ) operators (that is,
( ) would not capture, and (?: ) would capture).
The /n property would reflect on the RegExp object as `Noncapturing ==
true`.
Is there any
The /n property would reflect on the RegExp object as `Noncapturing ==
true`.
Lowercase noncapturing, right?
Yeah.
--Kyle
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
I'm definitely in favor of this | proposal, btw.
That sort of pattern certainly can be repeated if push comes to shove.
But I believe doing so is far inferior to dedicated, first-class
syntactical support to make the semantics absolutely unambiguous and
un-confusable with anything else.
d) At runtime, a function invoked as a non-method gets a dynamic
ReferenceError if it tries to refer to |this|. This would just be kind of
obnoxious, I think, since if the function wants to test whether it's been
called as a non-method it has to do something like
let nonMethod = false;
Do I understand you that the idea here is 'function' without the
'function' keyword? I think this has a pretty bad
backwards-incompatibility with ASI:
x = (x)
{ return x }
Which way should this parse?
My reading of Rick's gist was:
(x = (x)
{return x})
The outer ( ) removes the ASI
Let's ignore popularity level for the moment, no other proposal has analog
of `=` which is a solution for a real problem:
var self = this;
function callback() {
self
}
Maybe I missed something, but didn't Brendan's #-function proposal specify
lexical `this` binding, so that:
From: Dean Landolt
Sent: Sunday, May 08, 2011 10:17 AM
Unfortunately, we're back to the chicken-and-the-egg... if I could
guarantee that my code was the first to ever run on any page, almost none
of the problems I'm complaining about would be an issue, because I could
just make sandboxed
Many people, including me, would disagree. On matters of taste, I'd want
the committee to listen to all interested parties and try to pick the
solution that pleases the most people. That appears to be what's happening
here.
Based on what evidence are we concluding that the majority of the
It's a well known fact that overwriting anything in Object.prototype
(like
Object.prototype.toString, for instance) is a very bad idea, because it
breaks for-in looping.
Properties 'properly' added/updated using Object.defineProperty
{enumerable: false} do not break for-in afaik.
I wasn't
The malicious script could schedule patching newly loaded code
directly without even overwriting Object.prototype (eg. to reuse your
example, it could replace document.location.href occurences with a
string constant in the 'trustworthy' function source directly).
Not if the code in question is
Again, a smart library can only do that if it's guaranteed to be the
first code to run on the page. If not (which is usually the case), then
all bets are off, unless the language offers some protections.
All bets are probably still off. The malicious code that's first can load
the latter
Based on what evidence are we concluding that the majority of the
javascript developers want - syntax for functions? The fact that
coffeescript is the hot buzzword? Was there some developer-community wide
voting or poll that I missed? Or is it that a few vocal people on these
lists like it,
My first reaction to this assertion is to say: so? It's a rather moot
argument to suggest that code which can be altered before it's run isn't
trustable... of course it isn't. [...] because any malicious script (if
it's first on the page) can completely hijack another part of the page?
Yup, I
But, JSConf has just 150-200 JavaScript developers in attendance.
Right. The JS community has no borders, no government, no constitution, no
membership cards, no census... We welcome everyone. So we have no way of
instituting democratic institutions.
they are definitely not a representative
Good, we're making progress. Previously I was not responding to your
original request, I was responding to your response to Crock's message.
Hence our confusion about premises. Thanks for making your's clearer. As
for your original request, now that I better understand what you're
looking for,
Many JSON serializer implementations escape the / character, including for
instance PHP's json_encode(). However, JavaScript's own JSON.stringify()
does not. If you look at the grammar on json.org, as I read it, the escaping
of / is **optional**, since it is a valid UNICODE character, and it's
See http://wiki.ecmascript.org/doku.php?id=strawman:default_operator --
the proposal there is ?? and ??= since single ? is ambiguous after an
expression due to conditional expressions (?:).
The default operator doesn't address a significant part of what Dmitry is
asking for -- the . in the
The other (more awkward/obscure looking) way to do this is:
var a;
b a = c;
a = b c;
That is not the same thing. Your code assigns `b` to `a` if `b` is falsy .
The other code either leaves `a` as undefined (strictly doesn't assign) if
the test fails, or assigns it the value of `c` (no
See http://wiki.ecmascript.org/doku.php?id=strawman:default_operator --
the proposal there is ?? and ??= since single ? is ambiguous after an
expression due to conditional expressions (?:).
The default operator doesn't address a significant part of what Dmitry
is asking for -- the . in the
I'm not sure I see how this is really introducing an additional
ambiguity?
It is obviously introducing an ambiguity where none exists today. ?: is
indivisible, unlike if vs. if else.
I was referring to no additional visual ambiguity inside the ?: with respect
to operator precedence and how
In an LR(1) grammar, if vs. if-else or ? vs. ?: is a shift-reduce conflict
(to use yacc terms). It is an ambiguity. It can be disambiguated, but
please do not confuse disambiguation via shifting with no *real*
ambiguity.
My point is it IS disambiguated by the definition of operator
Brendan, you've asked for other coding examples where I use the pattern of
some variable being `undefined` or not to trigger different behavior (that
is, to use the variable or not). Here's two more:
1. I have a templating engine DSL (called HandlebarJS) I wrote (in JS),
which includes a
I don't see why you can't verify your expectation.
If you think you can verify your expectation, please write ECMAScript
interoperable test cases that show how to test whether an ECMAScript
engine is conform to your scheduling policy or not. It will be enough to
convince me.
Testing one timer
Nowadays the clamp is there because sites use |setTimeout(f, 0)| when
they really mean run this at 10Hz and if you run it with no delay then
they swamp your event loop and possible render wrong (e.g. the text
disappears before the user has a chance to read it).
I'm not convinced that this is
BTW, if you know that a property name is foo, why would you ever code
obj[foo] instead of obj.foo?
The most obvious reason is if the name of the property contains a character
which cannot be an identifier character in the property name... like a
unicode character, for instance.
Without
What I was saying is, if I run this program through V8 right now (with
its theoretical future support of setTimeout() included), then what will
happen:
function fn() {
print(hello);
}
for (var i=0; i10; i++) {
setTimeout(fn,i*1000);
}
That for-loop will finish very quickly (probably 1 ms).
* No clamping. Time runs as fast as the platform lets it run.
* The return value is not an integer but a unique unforgeable object for
canceling the event. No one without
that object can cancel that event.
This last point is something I was about to raise when starting to think
about
Kyle: If there was a way to determine which timers are currently queued,
would that solve your problem? That's probably the only thing I'm missing
right now from the timer api: Some array with all queued
timeouts/intervals. Maybe that's to prevent the clear attack mentioned
before, looping all
As I understand it, this type of thing was kept out of the language
proper intentionally, because of its strong dependency on host
environment. Some host environments may require tight and overriding
control of any event handling system, and exactly which types of
events (such as timeouts) are
There's LOTS of sites out there that still (unfortunately) do unsafe
overwriting/overloading of the native's prototypes. For instance, just a few
months ago, I ran across a site that was creating a Array.prototype.push()
implementation that was incompatible with the standard implementation.
Speaking as someone who has written and currently maintains a
*synchronous* server-side JavaScript environment (based on V8), I attest
to the statement that I would *not* like it if V8 had `setTimeout()`
(...etc) in it, because unless V8 were going to take care of that
completely black-box for
Aside from the JSON example of populating a dropdown list given (which I
will agree is a real if contrived use case), there has been a lot of talk
of thousands of web developers depending on preserving insertion order,
but not one concrete example -- do you have one?
Two examples I've seen
I didn't see a way to set the seed of Math.random(), so the
ECMAScript/Javascript version lacks this useful property.
Butting in, for a moment... I thought JavaScript seeded the PRNG with the
timestamp by default? Perhaps I'm totally off base, but that's long been my
assumption, and the
for debugging purposes when looking at
JavaScript errors reported in the browser's error console, for instance.
I'm interested in thoughts on either snippet's approach and the feasibility
of something like this?
--Kyle Simpson
___
es-discuss mailing list
es
?Brendan/all--
I just tested, and the first snippet (just `throw`ing the same error object)
indeed worked as I wanted (preserved original source/line-number context)
in: FF3.6/4, IE9, Saf5, and Op11. It only fails to preserve context in Chr8
(V8).
So, it would seem that my idea is valid
?FYI: There was already a similar bug filed with V8. I updated it to
indicate that I'm still seeing this happen with ReferenceError's.
http://code.google.com/p/v8/issues/detail?id=764
--Kyle
___
es-discuss mailing list
es-discuss@mozilla.org
What about adding an attribute to properties that somehow
identify which classes (in the prototype chain for protected)
have access to the object? I'll leave the somehow up in the
air, but you could introduce a [[Private]] attribute which, if not
undefined, says which context must be set (and for
82 matches
Mail list logo
