Allen Wirfs-Brock wrote:
On May 6, 2015, at 7:36 AM, Daniel Ehrenberg wrote:
In the draft ES6 spec, getting or setting array indices on detached
TypedArrays raises a TypeError. However, both V8 and SpiderMonkey
seem to return undefined from reads and silently succeed on writes.
These
Andreas Rossberg wrote:
On 29 April 2015 at 02:21, John Lenz concavel...@gmail.com
mailto:concavel...@gmail.com wrote:
I missed it, thanks.I know things will improve in time but I'm
just coming from a discussion with folks complaining about the
performance of generators and GC
Andreas Rossberg wrote:
I agree that we should have wildcard patterns. I also think that array
elisions are a non-solution, because you need a magnifier to read or
count them,
Agree.
and they square oddly with optional commas in the end.
Old rule: allowing one (and only one) comma at end
C. Scott Ananian wrote:
I'm just saying: it's not safe to spread an arbitrary array into
`arguments` unless the spec explicitly says that the number of
arguments is limited only by heap size (not stack size) or something
like that. The ES6 spec does not contain any such language.
We've
Allen Wirfs-Brock wrote:
Regardless, too late for ES2015. It will have to proposed as an
ES2016 change.
Could we errata quickly? Implementations should not ship the bug.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
Allen Wirfs-Brock wrote:
But the specified [[PromiseConstructor]] test doesn't really hurt
anything.
I've heard that before!
It's a wart implementations can avoid shipping, to avoid Murphy's-Law
compatibility constraints growing on top of it. You don't want a wart at
all, certainly not
Kevin Smith wrote:
So what would the ideal Promise.resolve semantics do? I'm not sure,
maybe use SpeciesConstructor instead of [[PromiseConstructor]]?
This removes the wart in my view, has no less integrity. C. Scott?
/be
___
es-discuss mailing
C. Scott Ananian wrote:
It seems to me that this is an incomplete feature that should have
been dropped from the spec.
Seems like.
I apologize for not noticing this sooner.
No need -- thanks for finding it.
Domenic, Kevin: the concern about Reflect.construct seems misplaced, but
in any
James Burke wrote:
So let's stay on this specific point: bundling will still be done even
with ES modules and a loader that would natively understand ES modules
in unbundled form. Hopefully the rest of my previous message gave
enough data as to why.
Not bundling in full; your previous post
James Burke wrote:
It is kind of sad that to use ES modules means to actually not really
use them at runtime, to transpile back to ES5-level of code, and
needing to ship a bootstrap loader script that allows slotting that
the ES5-level code into the ES loader. For the extra script and
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
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
___
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 bren...@mozilla.org
mailto:bren...@mozilla.org wrote:
The principle extends just fine
Honestly, you can't count on promises from implementors. Best to make
something kick-ass that pushes generator performance, gets adoption, and
engines feel the heat. Until then, profile twice, cut once -- in all
cases I've seen, the generator perf hardship was not on critical path.
/be
Jason
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
Alan Schmitt wrote:
We found this by looking into loop unrolling, so it would be great if
completion values could propagate across loop iterations.
Definitely. Thanks for finding this!
/be
___
es-discuss mailing list
es-discuss@mozilla.org
Michael Dyck wrote:
Unlike the current process, the post-ES2015 spec process requires two
shipping implementations before a feature is integrated into the spec.
While we're waiting for that, we anticipate proposal documents to
prepare for integration by being written as Ecmarkup/Ecmarkdown spec
Allen Wirfs-Brock wrote:
Well, they do for normal loop completions (according to the spec.) but not for
breaks. I this the latter is a bug. In particular, I think it is pretty
obvious that:
eval(“ {0; while (true) {1; break}; 2}”)
(single quotes might avoid the smart-dumb
Christoph Pojer wrote:
it doesn't have to be a bug. It asserts that if a is not
null/undefined, it must have a property b. This can be enforced
through static typing.
What do you mean? JS does not have static typing. Even if it got it via
SoundScript, the new mode would be an opt-in. The
a.d.be...@web.de wrote:
Hi,
I've just got bitten by
return getError().then(Promise.reject);
where `reject` threw an error that its `this` value was not a Promise
constructor.
Would it help to make the `C` constructor (in Promise.resolve, Promise.reject,
Promise.all, Promise.race
Nathan White wrote:
Am I crazy to think that Nil could allow the Existential Operator to
be used in assignments as well?
var a = undefined;
a?.b?.c?.d = 1;
console.log(a); // {b: {c: {d: 1}}}
Too powerful / abusive?
Too error-prone. E4X (ECMA-357) and languages such as Borland's
# March 24 2015 Meeting Notes
Brian Terlson (BT), Allen Wirfs-Brock (AWB), John Neumann (JN), Jeff
Morrison (JM), Sebastian Markbage (SM), Yehuda Katz (YK), Dave Herman
(DH), Alan Schmitt (AS), Lee Byron (LB), Domenic Denicola (DD), Kevin
Smith (KS), Andreas Rossberg (ARB), Brendan Eich
Erik Arvidsson wrote:
(Brendan Eich presents
https://gist.github.com/BrendanEich/4294d5c212a6d2254703)
Moves to stage
1 was lost from end of line here. I'll have a github repo instead of a
gist for this shortly.
/be
___
es-discuss mailing list
Caitlin Potter wrote:
6, 2015 at 5:42 PM, Brendan Eichbrendan at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss wrote:
/ Did you keep backward compatibility? `x?.1:y` must continue to work.
/
This is why I suggested a leading operator (`?a.?b()`) because it seems
like it would
Brendan Eich wrote:
Caitlin Potter wrote:
6, 2015 at 5:42 PM, Brendan Eichbrendan at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss wrote:
/ Did you keep backward compatibility? `x?.1:y` must continue to
work.
/
This is why I suggested a leading operator (`?a.?b()`) because
Ron Buckton wrote:
The reduce/reduce conflict recognizing a left sentential form '[' E ']'
vs. M '?' '[' E ']' shows the fatal ambiguity.
/be
There is also ambiguity due to ASI vs. a ConditionalExpression:
```
obj ? [ expr ]
:label
```
Ron
Colon goes after label :-P. But the
and
inevitably incurs future-hostility to extensions we may want, if not
outright bugginess.
All of this suggests prefix ? is the better course. Anyone have
counterexamples?
/be
Joe
On Mon, Apr 6, 2015 at 2:42 PM, Brendan Eich bren...@mozilla.org
mailto:bren...@mozilla.org wrote:
joe wrote
joe wrote:
By the way, I don't remember having grammar issues (I use a LALR
compiler-compiler). Looking at my code, it looked like I handled it
in the tokenizer stage; I added a COND_DOT token:
COND_DOT : \?\.
Did you keep backward compatibility? `x?.1:y` must continue to work.
/be
Yeah, and it would line up with cover grammar needed for
refutable-by-default patterns.
/be
Matthew Robb wrote:
On Mon, Apr 6, 2015 at 5:42 PM, Brendan Eich bren...@mozilla.org
mailto:bren...@mozilla.org wrote:
Did you keep backward compatibility? `x?.1:y` must continue to work
Implement it; user-test it; auto-check the grammar for ambiguity and
other problems.
/be
Christoph Pojer wrote:
So I take it most would prefer this as a prefix operator. What would
be the next steps involved to iterate on this idea?
On Mon, Apr 6, 2015 at 3:35 PM, Brendan
Axel Rauschmayer wrote:
There are two different aspects:
1. If you get an iterable, it sometimes matters whether iteration
restarts when you ask the iterable for an iterator.
Rather, if you have an object o and o[Symbol.iterator]() === o then you
have an iterator.
2. Self-iterability is
It was the 90s, when 16 bits seemed enough. Wish we could go back. Even
in 1995 this was obviously going to fail, but the die had been cast
years earlier in Windows and Java APIs and language/implementation designs.
/be
Claude Pache wrote:
(So, taking your example, the character is
Michał Wadas wrote:
First possible problem - of used in if statement can put iterator in
unexpected state or result in arbitrary side effects.
What iterator?
First, you shouldn't assume this would be based on the Symbol.iterator
protocol. I wrote something like @@hasInstance for instanceof
productions allow the contextual use of new
keyword-operators without breaking backward compatibility.
/be
Bergi wrote:
Brendan Eich schrieb:
From https://plus.google.com/+IanBicking/posts/PbXDtNF9Gg6:
Huh, for (attr in obj) goes along with if (attr in obj), but for
(item of array) doesn't have
Frankie Bagnardi wrote:
First, you shouldn’t assume this would be based on the
Symbol.iterator protocol.
Would |Object.create(null, {[Symbol.iterator]: value: ...})| work as
it does in for..of?
No, as with instanceof and @@hasInstance in general, you wouldn't get
membership test
Caitlin Potter wrote:
Well just to get the ball rolling, I’ve put together a markdown doc
for this
https://github.com/caitp/TC39-Proposals/blob/master/tc39-reflect-isconstructor-iscallable.md
It’s such a minor item that I’m not sure how much to add to it, so
maybe someone else will have a
Last thread:
https://esdiscuss.org/topic/add-reflect-isconstructor-and-reflect-iscallable.
Died off again.
There's no issue with ES7 vs. ES6 without a spec, and having a draft
spec at the right stage (1 for flagged implementation?) is the thing.
Who will do it?
/be
Caitlin Potter wrote:
From https://plus.google.com/+IanBicking/posts/PbXDtNF9Gg6:
Ian Bicking
Shared publicly - Mar 24, 2015
#Array
Huh, for (attr in obj) goes along with if (attr in obj), but for
(item of array) doesn't have an equivalent if (item of array)
There is a proposal I guess for a method, but only for
Domenic Denicola wrote:
Seeing as how I just produced a completely redundant message by
failing to read the other responses before firing off my own, let me
try to redeem myself with some more-original content.
(Nice post!)
It’s also important to realize that streams are not the only
Brendan Eich wrote:
Axel Rauschmayer wrote:
It’d be great if all iterables were indeed the same in this regard.
I didn't reply to this last sentence. I don't agree that all iterables
(we don't control the universe of such things, so perhaps you mean all
standardized or built-in iterables
Axel Rauschmayer wrote:
The way that `return()` is handled in generators (via try-catch) means
that the clean-up action is called in both cases: generator exhaustion
and generator closure. If you don’t use a generator then a clean-up
action in `return()` is only called if the iterator is
Jacob Parker wrote:
In the context of only objects and classes, is this format no-go?
Without the } that closes a concise method body, there's a new problem
to-do with computed property names:
class C {
m() this._m
[Symbol.iterator]() {/*...*/}
}
We need a delimiter. Could use ;
Mar 2015 8:37 am Brendan Eich bren...@mozilla.org
mailto:bren...@mozilla.org wrote:
Jacob Parker wrote:
In the context of only objects and classes, is this format no-go?
Without the } that closes a concise method body, there's a new problem
to-do with computed property names
Kyle Simpson wrote:
Totally disagree here. Anyone that's following the (Crockford) advice of not
using loops anymore and writing all recursion absolutely cares if such code can
be directly loaded into a browser or not.
LOL.
I don't think Crock was totally serious there... Let's get PTC
Andrea Giammarchi wrote:
I think the answer is still a static `[a, b]` as list of arguments to
apply, but I can see some lack of reflection capability ... or maybe
Reflect would solve this?
Yes, Reflect -- we want a mirror approach, not more magic object like
arguments or function.
/be
Axel Rauschmayer wrote:
Right. Always closing is much simpler. Otherwise, you’d have to check
whether everything was exhausted or not.
This is by design, FWIW.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
Brendan Eich wrote:
var y = (a) = a ? f : x++ (1);
evaluated (or is it syntactically valid at all)?
The problem with expression closures is precedence inversion: you have
LowPrec ~~ HighPrec ~~ stuff ending with LowPrec. The particular
nonterminals are AssignmentExpression
Bergi wrote:
Jacob Parker schrieb:
Either I'm wrong, or that's missing some parens. Assume the following
(the
only interpretation I can see to not throw a syntax error),
var y = (function (a) a ? f : x++)(1);
In which case, that could only return `f`, which when printed should
print
Jacob Parker wrote:
Either I'm wrong, or that's missing some parens.
No, test it yourself in Firefox (s/print/console.log/) or SpiderMonkey.
Assume the following (the only interpretation I can see to not throw a
syntax error),
var y = (function (a) a ? f : x++)(1);
In which case, that
You may be thinking of the change to make the var's intiialiser, e.g.,
for (var x = i in o) ...
illegal in ES6.
/be
Mark Ethan Trostler wrote:
Howdy,
Is this legal ES6 syntax:
for (var x in [ 1,2,3 ] ) { ... } //?
Can the 'var' be in there? There was alleged talk at some point about
Allen Wirfs-Brock wrote:
including these, in addition to the existing shorthand syntaxes,
should make the following examples work.
var x = { value: 3, toString() 'string', valueOf() this.value };
class x { constructor { this.value = 3; } valueOf() this.value }
what you show above
Jason Orendorff wrote:
But from the few data points I have, approximately 100% of web
developers, when they first hear template strings are in ES6, think
that means something like Mustache in the standard library. Some
initially try to use the feature that way and get frustrated. I expect
But we could extend the cover grammar with some work. You'd have to push
ArrayLiteral and ObjectLiteral down from PrimaryExpression alternative
right-hand sides, to live under
CoverParenthesizedExpressionAndArrowParameterList.Seems do-able --
anyone see a fatal problem? Could be an ES7
Allen Wirfs-Brock wrote:
On Mar 18, 2015, at 9:34 AM, caridy wrote:
Kyle, same answer, `let x = y` is just an assignment. btw, you cannot change `y` in that module, that's a static error.
Assignment to 'y' a dynamic error. A while ago we eliminated all early errors that required static
Right, Mark pointed out shadowing as an advantage of using just a
getStack lexical name. Need to see more to judge pleasantness.
/be
John Lenz wrote:
I'm under the impression Error.getStack would suffer the same scoping
issues and it would have to be a module import that a custom loader
John Lenz wrote:
b) It differs so wildly between platforms that cross-web content
can't rely on it.
It exists everywhere and from where I sit it is pretty essential and
there is lot of wiring that exist to propagate and preserve stack traces.
Yeah, I'd be careful concluding too
Coolwust wrote:
I have one more question, why `yield` and `in` keywords are so
special? When can I treat `yield` and `in` as the non-reserved-word?
You can't treat `in` as an unreserved identifier, in any event. It has
been reserved since JS1 in 1995, de-jure in ECMA-262 Edition 1 (ES1).
Luke Scott wrote:
Currently you can do this anyway:
const C = class {};
if (someCondition) {
C = class OtherC {};
}
You can't: const is assign-once in ES6, and only from the initialiser in
the declaration.
/be
___
es-discuss mailing list
Eric Elliott wrote:
Thanks Brendan. This is very helpful indeed! Where can I learn more
about that solution?
I know of this gist:
https://gist.github.com/wycats/0bd8f14066e44ed7b90e. Cc'ing wycats.
I assume for backwards compatibility, this will not be default
behavior, so we're going to
Erik Arvidsson wrote:
Traceur does not give any history on this but I also remember having
this discussion in a f2f meeting. It was all about js has always been
mutable, lets not change that. If you want immutability you have it
with `const f = class {}`.
Yeah, that fits the groove laid down
Allen Wirfs-Brock wrote:
This is novel weirdness.
In C++/Java/C# etc. you don't see it because the corresponding
declarations create immutable bindings. I agree that it would have
been nice of we could have done that.
Why could we not have?
I asked this up-thread. What was the rationale
Andreas Rossberg wrote:
For the record, I strongly dislike the function behaviour. Turning a
function expression into a declaration silently changes the meaning of
internal recursive references, in ways that many people find very
surprising. That is an unnecessary pitfall.
Also for the
Leon Arnott wrote:
I do, however, have a small personal grievance about the class syntax:
why doesn't it use commas to separate method and accessor properties?
Consider the disconnect. Object literal: commas. Array literal:
commas. Class literal: no commas. I appreciate that classes are not
Leon Arnott wrote:
Well, they're a distinct special form that can be used in expression
position, and evaluates to a function, so they're definitely, to bring
back an old coin, quasi-literal. (I personally think your reasoning
entails that arrows aren't function literals because of their
Matthew Robb wrote:
On the issue of calling class constructors, I would AT LEAST have
preferred implicit new on all calls to class constructors. Sure you
might get extra allocation weight but the way it stands now seems like
it could only lead to errors in people's assumptions...
An error
Allen Wirfs-Brock wrote:
That's precisely what I thought, until I started thinking about what
it'll actually be like to use this feature as a programmer.
To me, this issue explains why functions are the way they are.
Not my understandings. Function declarations are the way they are
Claude Pache wrote:
A simple solution is to make:
class Foo { /* ... */ }
equivalent to:
const Foo = class Foo { /* ... */ }
instead of the equivalent desugaring with `let`.
The ES6 design has classes as sugar, which is an imprecise slogan, but
useful. For some reason we settled
Just to be clear, I agree with you that we should not rush to add
special forms where combinators may suffice. However:
Claus Reinke wrote:
We just got rid of the 'this' workarounds, and it cost us a whole
second set of function expressions.
We would have had this problem anyway. When I did
Andrea Giammarchi wrote:
but how would you drop that listener, if that's even a concern of
yours, beside the usage of `function`?
I'm not addressing your particular issue just yet -- patience!
Does I agree with Mark means already two think arrows function
should never be self-reference-able?
Rick Waldron wrote:
function Component(target) {
let a = function.arguments;
target.on(click, event = {
// In here, `arguments` refers to the `arguments` object
// that was created for this invocation of Component,
// which makes sense because that object has no sense of
//
This doesn't address the symbol idea, but I don't see the motivation for
that. A well-known symbol doesn't help usability or integrity. Matthew,
could you please link to the twitter thread?
Anyway, the reason 'name' is a normal property identifier and not a
symbol is because it's a de-facto
Mark S. Miller wrote:
My other suspicion: The previous failure of this proposal was before
many people had much hands on experience using higher order functions
in JS as a normal alternative to control structures. Now that we all
have, the need for a non-local escape may be more visceral.
Benjamin (Inglor) Gruenbaum wrote:
Of course this example is contrived! It's the simplest example I could
think of. I do think it stands for every example of any iterator that
takes any input from `.send` or `.throw`. I have plenty of other
contrived examples (implementing `fork` like this by
No one has taken my bet :-P.
/be
Mark S. Miller wrote:
On Sun, Feb 22, 2015 at 3:12 PM, Mark S. Miller erig...@google.com
mailto:erig...@google.com wrote:
Array.prototype has reverted to being an empty initially empty
exotic array object.
Function.prototype remains a no-op
Salvador de la Puente González wrote:
Yep. This was already discussed in the topic I mentioned before. Just
to remember, the real problem with tee() is that the generators are
not actually independent as you can not .send() different information
to each one to make them diverge.
Why not?
Minor wording nit-pick/question:
In what sense is an operator form declarative? I get that it's not an
API -- special form is special ;-). But what's being declared if the
only grammar extension is to the expression grammar?
/be
Allen Wirfs-Brock wrote:
Here is a new proposal for a
Tab Atkins Jr. wrote:
(Not saying anything needs to be added right now. Just pointing out
the specifics, as it seemed you were talking past each other.)
Thanks, I was thinking beyond tee as a generic, which copies (requiring
a set-aside, could be a lot of memory). If the cliff leads to
Allen Wirfs-Brock wrote:
Note that the lambda abstraction technique also can support a dynamically
provided method name:
let aVarNamedMixin = (obj, name) = obj mixin {
[name] () {
//do something
super[name]()
}
}
That's not bad. Never reach for eval where a function will do.
I wonder why we cannot have toMethod, in due course. You had suggested
the ES6 signature with a second parameter, with default value:
Function.prototype.toMethod(homeObject, methodName = this.name);
With a function.name spec'ed in ES6, that might be enough to address the
concerns raised by
Benjamin (Inglor) Gruenbaum wrote:
Why not? The generator would switch on sent value, in a loop.
Well, let's say we have an iterator that does nothing once, returns
what was sent to it the first 5 times and then is done:
```js
function* gen(){
var res = yield;
for(var i = 0; i 5; i++){
As the comments from Tab Atkins and John Lenz there suggest, this is
best done above the level of the standard, for now. If we need to roll
up itertools including tee in ES7 (I am pretty sure we do), the best way
to get there is via github -- not by prematurely standardizing APIs or
Mark Miller wrote:
There, Boris writes:
Conceptually, using the global of the realm of the function involved
(i.e. the Chrome/Firefox/IE10 behavior) makes sense to me.
Me too. This is in keeping with the spirit of lexical scoping. It is
as if these built-in functions have lexically captured
Has any engine tried implementing the ES6 changes from ur-instances to
plain objects?
We are kidding ourselves about this change being web compatible if the
answer is no. I would bet real money that something will break. Who
wants to wager?
/be
Allen Wirfs-Brock wrote:
On Feb 19, 2015,
Cyrus Najmabadi wrote:
Ok. Thanks for confirming our read of the grammar. Is this shown on
any breaking changes list anywhere?
It should be -- who is maintaining such a list?
Cc'ing Oliver, I believe he found a `for (var x = i in o)` use in the
wild but it was evangelized successfully.
in the future without breaking anything.
Allen
On Thu, Feb 12, 2015 at 9:45 PM, Brendan Eich bren...@mozilla.org
mailto:bren...@mozilla.org wrote:
Please file a bug, ASAP. Thanks,
/be
Michael Ficarra wrote:
Is there any reason why a trailing comma is not allowed
Andreas Rossberg wrote:
On 16 February 2015 at 15:41, Andrea Giammarchi
andrea.giammar...@gmail.com mailto:andrea.giammar...@gmail.com wrote:
Common pattern is to poll.next() a yield until its `done` property
is `true` so that a value can be used.
This is I believe the common case
Kevin Smith wrote:
Have you tried writing a combinator which does exactly that? Take a
look at zip in python.
Right -- we don't add new syntax lightly, we'd need to see zip used a
lot, and at some irreducible-without-special-form overhead.
/be
Please file a bug, ASAP. Thanks,
/be
Michael Ficarra wrote:
Is there any reason why a trailing comma is not allowed in an
ArrayBindingPattern when it has a BindingRestElement? I noticed
yesterday that my parser was erroneously allowing these, but the
inconsistency with both ArrayLiterals and
This is indeed a change from ES5. Has any major engine or other
test-vehicle tried to see how web-compatible it is?
/be
Caitlin Potter wrote:
I believe making String non-exotic has been discussed, and if this has changed
from ES5, it could be related to that.
Mark Volkmann wrote:
I'm curious why one of the public symbols has a name that ends with
Tag (toStringTag), but the others don't (such as toPrimitive).
Maybe toStringTag should be changed to toString.
That would be the wrong name -- the Tag is specific, particular to the
purpose of this
Axel Rauschmayer wrote:
Can you explain what you mean by “same-named”? You want `Symbol.for()`
to have the same casing as `Symbol.iterator`?
No, I mean we would normally use iterator (and had __iterator__ in
SpiderMonkey, then '@@iterator' I believe), not ITERATOR. Python's
dunder-bracketing
Some tasteful inconsistency (the hobgoblin of big minds) is required
here. We want the well known symbols' names as static properties of
Symbol to be same-named.
/be
Mark Volkmann wrote:
Agreed, like at the constants on the Math object.
---
R. Mark Volkmann
Object Computing, Inc.
On Feb 6,
Benjamin (Inglor) Gruenbaum wrote:
Cancellation of promises is something that has been debated several times (not
sure if at all in esdiscuss).
Many times:
https://www.google.com/search?q=site%3Aesdiscuss.org%20cancel%20promise
Google site: search is your friend.
/be
https://esdiscuss.org/topic/set-iterators
(site: search again, but I admit I used deterministic and tyler close
keywords to help.)
/be
Benjamin (Inglor) Gruenbaum wrote:
Hi, I recently answered a question on StackOverflow about set
iteration order which made me read the spec.
I remember
Benjamin (Inglor) Gruenbaum wrote:
We don't all have superpowers and know how to find targeted topics
from 3 years ago :)
(I did google search, I'll work on my list search-fu)
This one didn't require my elephantine memory :-P.
Benjamin (Inglor) Gruenbaum wrote:
For example - I don't need to know or understand what
`[[ReferenceGet]]` is to understand something written in this sort of
style: https://wiki.php.net/rfc/combined-comparison-operator
Not bad -- we are using gists and github markdown but could build that
Allen Wirfs-Brock wrote:
Changes include:
*
Removed ‘new super()’ syntax
*
new.target meta-property no longer highlighted as tentative.
*
Methods defined within class definitions are now non-enumerable
*
Classes defined as class extends null {...} are now consider to be
Mark S. Miller wrote:
On Mon, Feb 2, 2015 at 8:21 AM, Felix Kling l...@felix-kling.de
mailto:l...@felix-kling.de wrote:
With ES6 having a production rule Declaration and ES5 having
FunctionDeclaration, I'm curious why a variable declaration (as
we say), officially
Felix Kling wrote:
That made me wonder why /VariableStatement/ was a /Statement/ to begin
with? Maybe the concept of a declaration wasn't really developed
back then, but then what was the reasoning for /FunctionDeclaration/
not being a /Statement/ (was it even part of ES1? I don't know) ?
Please drop the crappy us vs. them talk. If you read this thread,
and others on esdiscuss.org, you can see TC39 did not keep ignoring
feedback. Yeesh!
We (TC39 includes web developers, W3C TAG members, WHATWG members and
cofounders, all well-connected to others working with and on WebIDL)
101 - 200 of 4618 matches
Mail list logo
