RE: Observable GC

https://w3ctag.github.io/design-principles/#js-gc From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Michal Wadas Sent: Friday, October 20, 2017 08:07 To: es-discuss@mozilla.org Subject: Observable GC Hi. Is there any comprehensive answer about why ability to observe garbage

Re: Stream + async await

That is not why. From: Jan-Ivar Bruaroey Sent: Aug 1, 2017 3:47 PM To: es-discuss@mozilla.org Subject: Re: Stream + async await Because a promise is not a control surface of the asynchronous action fulfilling it; confuses owner with consumer.

RE: Stream + async await

https://github.com/tc39/proposal-async-iteration From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Naveen Chawla Sent: Tuesday, July 11, 2017 09:24 To: es-discuss@mozilla.org Subject: Stream + async await It'd be great to have async stream constructs such as:

RE: Naming convention for multi-word identifiers with initialisms

https://w3ctag.github.io/design-principles/#casing-rules From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Alexander Jones Sent: Tuesday, July 11, 2017 08:07 To: es-discuss@mozilla.org Subject: Naming convention for multi-word identifiers with initialisms Occasionally this

RE: Microtask scheduling

The work has since moved into the specification that defines the event loop, i.e. the HTML Standard: * https://github.com/whatwg/html/issues/512 * https://github.com/whatwg/html/pull/2789 From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Isiah Meadows Sent:

RE: Are thrown errors in a try block considered to be handled even if there's no catch block?

Indeed, you cannot replicate dispatchEvent’s behavior, because it catches the error, then uses a browser-specific primitive “report an exception”. Over in the HTML spec, we’ve suggested exposing that primitive to users, but it hasn’t garnered sufficient implementer interest; see

Re: Intercepting sets on array-like objects

I'm not really sure how you're expecting to get an answer "according to TC39." One member had replied and given his suggestion. I don't think it's a good one for new APIs; I think new APIs should use arrays and not type check on sets but at processing time. I'm sure there will be many other

Re: Unicode non-character being treat as space on Firefox/Chrome

We should probably move this to a GitHub issue then, so ES can have clarity on it. If it helps, I am pretty sure (although I should double-check) that HTML treats such noncharacters as conformance errors (i.e. external tools like validators will warn you about them), but does not let them

RE: Would it be possible to add “await on first use” to the language?

We already have that feature in the language: it’s called await. Just rewrite the example like so, instead of using /* pause to await x */ comments: async function makePizza(sauceType = 'red') { let dough = makeDough(); let sauce = await makeSauce(sauceType); let cheese =

Re: Cancel Token proposal withdrawl

Why do you say "regarding performance"? That seems made up with no evidence. From: Isiah Meadows Sent: Jan 5, 2017 20:09 To: es-discuss@mozilla.org Subject: Cancel Token proposal withdrawl The [latest proposal][1] has been withdrawn due

RE: Object.equals() and Object.clone()

The biggest problem with structured clone is that there’s no way to just invoke it directly. Doing so has been proposed a few times, most recently at https://github.com/whatwg/html/issues/793, but no implementers have expressed interest. From: es-discuss [mailto:es-discuss-boun...@mozilla.org]

RE: Endorse an unambiguous syntax for ES2015 modules

From: martin heidegger [mailto:martin.heideg...@gmail.com] > Thank you for taking the time to answer. For some reason it seems like > I framed it to be a Node.js specific issue. In my understanding the current > ES2015 module specification is ambiguous regarding backwards compatibility. >

RE: Endorse an unambiguous syntax for ES2015 modules

From: Jordan Harband [mailto:ljh...@gmail.com] > An alternative answer to "What is the problem for the TC39 to doing the > endorse this effort?" is, it hasn't been presented to the committee yet. So, > it's a little soon to declare that there is or is not a consensus, or that > TC39 is doing

RE: Endorse an unambiguous syntax for ES2015 modules

As has been discussed many times, TC39 doesn’t need to endorse Node placing host-environment-specific restrictions on its inputs. They already impose restriction that CJS modules be FunctionBody, instead of the top-level Script production in the spec. Similarly, they can create their own

RE: Reflect.hasOwn

Reflect is a namespace that contains the proxy traps (it’s a bit of an unfortunate name), so we shouldn’t be adding things to it that are not part of the meta-object protocol. A new namespace, or using Object, might be OK. I think that it will still be controversial, since this proposal is in

RE: Why ES6 introduced classes yet `Symbol` not to be used with `new`?

I believe, but am not sure, that we also decided we would follow that pattern for any future primitive types, since in general constructing wrapper objects is a bad idea. (I want to say that wrapper objects themselves are a bad idea, but I think the conclusion was more subtle than that... they

RE: Why ES6 introduced classes yet `Symbol` not to be used with `new`?

Symbol is not a class. From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of /#!/JoePea Sent: Sunday, August 14, 2016 18:31 To: es-discuss Subject: Why ES6 introduced classes yet `Symbol` not to be used with `new`? It seems like `new Symbol()` would be

RE: Function constants for Identity and No-op

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Mark S. Miller > What's the issue with document.createElement('object')? It's a callable exotic object. >> On Wed, Aug 10, 2016 at 7:20 AM, Michał Wadas >> wrote: >> Function.isFunction? :D

RE: extending an ES6 class using ES5 syntax?

I believe this will work in most cases: ```js function B() { const obj = new A(); Object.setPrototypeOf(obj, new.target.prototype); // or B.prototype, but if you derive from B you'll have to do this dance again // use obj instead of this return obj; } ``` Also, in general you should

RE: Re: Tracking proposals should be standardized with issues

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of G. Kay Lee > Unfortunately, the latest stage 0 proposal (Object enumerables), which is an > outside contribution (in [the > list](https://github.com/tc39/ecma262/blob/master/stage0.md) the column > header says "champion"

RE: Subject=Re: Re: Better way to maintain this reference on event listener functions

To give some clarity to "whose concern is it", the idea of it being an ES concern is that this is a concern for all APIs that accept a callback. addEventListener is a simple example. I think ES has already given an answer to this question: `Function.prototype.bind`. I'm not sure what the OP

RE: Async iteration

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Isiah Meadows > By the way, I think observables are getting more headway than async > generators. This is very inaccurate. They have gotten more conference talks, but not more committee headway.

RE: Re: Provide hooks for Content Security Policy (CSP)?

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Ron Waldon > Are there CSP benefits for other JavaScript environments (e.g. Node.js)? Yes; it is something that could in theory be exposed through Node's vm module (i.e. Realm creation API), which would help certain

RE: Provide hooks for Content Security Policy (CSP)?

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Andrea Giammarchi > Can anyone explain with few words what does this change actual mean for JS ? It means that JS will now specify how it has been implemented already in every browser, in a more rigorous way that allows the

RE: Weak Reference proposal

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Mark S. Miller > On Tue, Feb 16, 2016 at 7:04 PM, Isiah Meadows > wrote: >> >> I know this is only tangentially related, but I just remembered weak refs >> are required for a fully conforming

RE: A promise that resolves after a delay.

I think this is a reasonable API, but ES is not the spec for it. ES does not have a proper concept of an event loop, and definitely not a proper concept of time. Note that setTimeout is not defined in ES, but instead in HTML: https://html.spec.whatwg.org/#dom-windowtimers-settimeout It might

RE: File Type for Module Goal

If you would like to register a MIME type with somebody, anybody at all, then https://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority is probably the right place to do so. They don’t really deal with file extensions, besides saying that registrations should include a few commonly used

RE: File Type for Module Goal

com/library/manuals/2000/javascript/1.5/reference/> From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Domenic Denicola Sent: Monday, January 25, 2016 23:22 To: Bradley Meck <bradley.m...@gmail.com>; es-discuss <es-discuss@mozilla.org> Subject: RE: File Type for M

RE: Object.getOwnPropertyDescriptors still at stage 0

I’ve opened a number of minor, mostly-editorial issues on the proposal. In general, how much more work you need to do depends on how many stages you and your TC39 champion (who is it, by the way?) plan to advance the proposal at the next meeting. Looking through

RE: Promises as Cancelation Tokens

In general I agree that there is a nice conceptual symmetry, but IMO the day-to-day impedance mismatch would be simply too great. Compare: ```js async function f(cancelationToken) { cancelationToken.then(() => console.log("FYI you have been canceled")); await

RE: Promises as Cancelation Tokens

From: Kevin Smith [mailto:zenpars...@gmail.com] > And what's the deal, is it canceled or cancelled?  : ) This is kind of the worst. Previous discussion at https://github.com/promises-aplus/cancellation-spec/issues/4. Data seems to favor cancelled: -

RE: Confusion with Object.prototype.toString and primitive string datatype

This mailing list is largely meant for the further development of JavaScript as a language (new feature design, spec review, etc.), and not for questions on how JavaScript works. StackOverflow is indeed a better venue for such questions. From: es-discuss [mailto:es-discuss-boun...@mozilla.org]

RE: Re: Backward running version look-behinds

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Yang Guo > - We have a spec draft: http://claudepache.github.io/ecma262/#sec-pattern, > http://claudepache.github.io/ecma262/#sec-pattern > - We have champions: Gorkem Yakin, Nozomu Katō and Brian Terlson Hmm, but none of the

Re: resolve()/reject() on Promise subclasses and @@species

All uses of @@species are to be removed from Promise.race and Promise.all. The committee achieved consensus on this, without you. From: es-discuss on behalf of C. Scott Ananian Sent: Wednesday, November

Re: resolve()/reject() on Promise subclasses and @@species

I still think everything should go through @@species. I don't understand the utility of @@species if it is not uniformly applied to constructing new instances (in both instance and static methods). But it seems that ES15 decided to only use @@species for instance methods so I guess that's where

RE: Any reason template string with empty interpolation placeholder (`${}`) throws?

If there were to be a value for `${}`, `undefined` makes more sense to me than the empty string as a default “nothing” value. From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Caitlin Potter Sent: Thursday, October 22, 2015 19:20 To: Mark S. Miller Cc:

RE: The name of Array.prototype.includes

https://github.com/tc39/Array.prototype.includes#why-includes-instead-of-has > -Original Message- > From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Axel > Rauschmayer > Sent: Tuesday, October 13, 2015 16:33 > To: es-discuss mailing list >

Re: Exponentiation operator precedence

I object to #4. Disallowing perfectly reasonable math expressions (Claude's is a good example) makes this operator too surprising to include in the language. From: Brendan Eich Sent: Sep 24, 2015 13:18 To: Mark S. Miller; Claude Pache Cc: es-discuss Subject: Re:

RE: System.import()?

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of James Burke In the spirit of the extensible web, defining these lower level APIs and more of the loader would make it possible to use custom elements to help prototype a module tag. The custom element mechanism can be used

RE: System.import()?

From: Jason Orendorff [mailto:jason.orendo...@gmail.com] HostResolveImportedModule is widely implemented by compilers, though not by browsers. People are writing, using, and sharing ES6 modules today. So what is your proposal then? Just standardize the node module resolution algorithm, since

RE: System.import()?

From: Jason Orendorff [mailto:jason.orendo...@gmail.com] Here's what I had in mind: I have re-read this a few times and still don't understand how you expect this to be implemented in a standards-compliant way given that HostResolveImportedModule is not standardized. It doesn't seem to

RE: Please help with writing spec for async JSON APIs

My understanding of most streaming JSON use in Node.js is that it actually is newline-delimited JSON. That is, each line is parsed, delivered, and processed as a single chunk containing a JSON value, and the streaming nature comes from the incremental processing and backpressure as applied in

RE: Extensible destructuring proposal

From: Samuel Hapák [mailto:samuel.ha...@vacuumapps.com] Could you please explain it on example? Let’s say I have ``` let book = Map{author: {name: “John”, surname: “Doe”}, birthdate: “10-10-1990”}; ``` How would you extract `birthdate`? How would you extract `name`? Your syntax here

Re: Extensible destructuring proposal

Well, the spec says they are ordered, so I'm not sure where you're getting that from. From: Bergi a.d.be...@web.de Sent: Jul 21, 2015 8:53 AM To: Domenic Denicola; es-discuss Subject: Re: Extensible destructuring proposal Domenic Denicola schrieb: For maps you can just do ```js const

Re: String.prototype.trimRight/trimLeft

They're already shipping with the wrong names in every browser. From: Norbert Lindenberg ecmascr...@lindenbergsoftware.com Sent: Jul 20, 2015 23:25 To: Dmitry Soshnikov Cc: Norbert Lindenberg; Domenic Denicola; es-discuss Subject: Re: String.prototype.trimRight/trimLeft These methods should

RE: Extensible destructuring proposal

For maps you can just do ```js const [[k1, v1], [k2, v2], ...rest] = map.entries(); ``` There is no need to add more complexity to object destructuring (which should only be used for objects and their string keys). -Original Message- From: es-discuss

RE: Instance bound class methods

To: Domenic Denicola Cc: Matthew Robb; es-discuss@mozilla.org es-discuss Subject: Re: Instance bound class methods Domenic, would you care to propose an alternative that is concise and memory efficient if it is an anti-pattern? That would be helpful and constructive (your comment, not so much

RE: for statement with index and value

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Matthew Robb Why not use the new meta syntax? This is pretty ingenious. If I thought this was a real problem that needed solving, I'd definitely go this route. (But, I think that using .entries() and destructuring is fine,

RE: for statement with index and value

From: Tingan Ho [mailto:tinga...@gmail.com] But they aren't clean solutions to a wildly popular problem. I disagree. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Clarification for derived promises

Yes. On Tue, Jul 14, 2015 at 10:10 AM -0700, Nicholas C. Zakas standa...@nczconsulting.commailto:standa...@nczconsulting.com wrote: Hi all, I'm trying to wrap my head around derived promises and wanted to ask for a bit of clarification around how `Promise.resolve()` works from a derived

RE: Instance bound class methods

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Brendan Eich You're counting on the property assignment being moved into the constructor, where `this` is bound. In a class body in ES6 (without property assignment extension), especially in the top level where method

RE: treated as a module if ...

To be explicit: there is no way to look at a string of JavaScript text and tell whether it should be treated as a module or a script. In many instances the same string can be treated as both. The decision is made by the execution environment. ___

RE: Will any new features be tied to constructors?

From: Anne van Kesteren [mailto:ann...@annevk.nl] I don't see how this matters given that Dmitry's design depends on not executing JavaScript while constructing the element. Whereas if you put this[Element.init]() in the constructor it totally would. Dmitry's design does *not* depend on

RE: Will any new features be tied to constructors?

From: Anne van Kesteren [mailto:ann...@annevk.nl] In a world where custom elements are normal subclassed objects, they would just call super() from the constructor to set the browser-supplied bits and then add whatever else is needed themselves. Yes, that is the Dmitry proposal. Or are

RE: Will any new features be tied to constructors?

From: Anne van Kesteren [mailto:ann...@annevk.nl] Fair, but it does depend on that not always being invoked at the same time as the constructor. So even if not being lexically part of the constructor was fine, you could still not depend on it being invoked at the same time. Yeah, you're

RE: Will any new features be tied to constructors?

From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com] Do one has yet explained to me, what is wrong with simply initially inserting a dummy (generic) custom element node during DOM parsing and latter (after the required JS code has loaded) replacing that node with a new more specific

RE: Will any new features be tied to constructors?

From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com] This is model is, to a first approximation the C++ model and the also the model the ES currently uses for built-ins so I don't expect that UA allocators will have significant difficulties supporting it. Really? Right now the UA

RE: Will any new features be tied to constructors?

@mozilla.org Subject: Re: Will any new features be tied to constructors? On 7/1/15 11:12 AM, Domenic Denicola wrote: Right now the UA allocators for all elements contains a single private slot, a pointer to the backing C++ object. Just as a note, this is true conceptually in the specifications

RE: Will any new features be tied to constructors?

Allen, Kevin: I think the key question about private state and how it interacts with Anne's question is this. Given a base class looking roughly like ```js class HTMLElement extends Element { constructor(...) { super(...); // ...other stuff... this[Element.init](); } } ```

RE: Will any new features be tied to constructors?

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of C. Scott Ananian But the design might work well as a proxy object? It could delegate to the real object, with its private slots, after that object is created. We briefly discussed this with the V8 team. Their opinion was

RE: Will any new features be tied to constructors?

From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com] no, not in the way that I believe you intend Can you explain why? Is the design you and Kevin have been working on based on lexical restrictions? It isn't that subclass specific private state initialization must be performed in the

RE: RegExp.escape()

All of these should be building on top of RegExp.escape :P From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Mark S. Miller Sent: Saturday, June 13, 2015 02:39 To: C. Scott Ananian Cc: Benjamin Gruenbaum; es-discuss Subject: Re: RegExp.escape() The point of this last variant

RE: Example of real world usage of function bind syntax

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Matthew Robb ​​I would be significantly less excited about it if this happens. The ability to pass around lightly bound references to methods is a big deal imo and a large part of the value in this proposal. Definitely

RE: Example of real world usage of function bind syntax

. On Thursday, June 11, 2015, Domenic Denicola d...@domenic.memailto:d...@domenic.me wrote: From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Matthew Robb ​​I would be significantly less excited about it if this happens. The ability to pass around lightly bound references

RE: Fixing `Promise.resolve()`

From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com] I don't think we discussed the possibility of Promise subclasses with different promise signatures at the May meeting; we mainly focused on the expectation that SubPromise.resolve(x) should yield an instance of SubPromise. Yeah, and to

RE: Fixing `Promise.resolve()`

Yes, I read that thread and still stand by my position. From: canan...@gmail.com [mailto:canan...@gmail.com] On Behalf Of C. Scott Ananian Sent: Wednesday, June 10, 2015 11:39 To: Domenic Denicola Cc: Allen Wirfs-Brock; Axel Rauschmayer; Mark S. Miller; es-discuss list Subject: Re: Fixing

RE: Fixing `Promise.resolve()`

Regardless of whether or not you agree, that was the original motivation for its introduction. From: canan...@gmail.com [mailto:canan...@gmail.com] On Behalf Of C. Scott Ananian Sent: Wednesday, June 10, 2015 11:45 To: Domenic Denicola Cc: Allen Wirfs-Brock; Mark S. Miller; es-discuss list

RE: Fixing `Promise.resolve()`

Allen, that change seems wrong. I thought we were only changing the IsPromise steps. The actual construction should still go through species. If nothing else, it should do so for consistency with reject. The motivation of @@species, as I understood it, was to allow alternate subclass

RE: Promise sub-class: super((resolve, reject) = this) ?

Hmm I am pretty sure Babel et al. are correct here in not allowing this. The super call needs to *finish* before you can use `this`. Chrome also works this way. The correct workaround is ```js let resolve, reject; super((a, b) = { resolve = a; reject = b; }); // use this ```

RE: Actual WeakSet Use Cases

WeakSets are perfect for branding and are how I would expect web platform class branding to be explained. ```js const foos = new WeakSet(); class Foo { constructor() { foos.add(this); } method() { if (!foos.has(this)) { throw new TypeError(Foo.prototype.method called on

RE: Maybe we need a reflect API to iterate over instance members

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Gray Zhang I’m just wondering is there any reason that Reflect API is not suitable to provide such functionality? Reflect currently contains only methods which correspond to proxy traps. There has been talk of extending it

RE: How can I synchronously determine a JavaScript Promise's state?

I will repeat to you what I said on Specifiction: To get a standard API for this, you'll need to convince the JavaScript standard committee, as well as the browser vendors, that your use case is widespread and important enough to be worth the standardization and implementation burden, and

RE: import ModuleSpecifier

It is syntactically valid, but there is no specification for what the module specifier string should contain. Traceur has one rule, and if you’re using Traceur you need to follow Traceur’s rules. I’m sure other transpilers have their own chosen rules. In a hypothetical future where browsers

RE: import ModuleSpecifier

a loader that is more in line with their current ES5 one, and transpilers will probably contain a way of switching between io.js and browser behaviors, at the bare minimum. From: Mark Volkmann [mailto:r.mark.volkm...@gmail.com] Sent: Sunday, May 31, 2015 19:37 To: Domenic Denicola Cc: es-discuss

RE: Providing object iterators beyond just Object.keys()

http://lmgtfy.com/?q=site%3Aesdiscuss.org+object.values From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Gijs Kruitbosch Sent: Tuesday, May 26, 2015 10:33 To: es-discuss@mozilla.org Subject: Providing object iterators beyond just Object.keys() Hello, When writing JS loops

RE: let function

They can, in fact, be scoped in a for loop. From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Andrea Giammarchi Sent: Thursday, May 14, 2015 14:53 To: Kevin Smith Cc: es-discuss@mozilla.org Subject: Re: let function I guess 'cause that cannot be scoped, let's say in a for

RE: let function

Not all browsers have implemented the spec yet. But you should read the spec before proposing changes to it! From: Alexander Jones [mailto:a...@weej.com] Sent: Thursday, May 14, 2015 15:16 To: Domenic Denicola Cc: Andrea Giammarchi; Kevin Smith; es-discuss@mozilla.org Subject: Re: let function

RE: Streams and Observables

See my response when you asked this question a month ago: https://esdiscuss.org/topic/promises-vs-streams#content-5 Especially, follow the links. To correct a few misconceptions: streams analogous to a list of values there are many things in the async/plural category, not just streams

Re: *.empty Idea

It's fine to propose something to make maps immutable. Just don't call it Object.freeze. On Thu, Apr 30, 2015 at 11:56 AM -0700, C. Scott Ananian ecmascr...@cscott.netmailto:ecmascr...@cscott.net wrote: Can you make an alternative proposal that still preserves the essential property of

RE: Subclassing ES6 objects with ES5 syntax.

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of C. Scott Ananian But in the code given previously, I've used `Object.setPrototypeOf` to effectively change the type of the object -- but [[PromiseConstructor]] doesn't follow along. That is exactly the kind of tampering

Re: Subclassing ES6 objects with ES5 syntax.

It's possible Reflect.construct has introduced a security hole that was not present before the recent instantiation reform. Hopefully Mark can comment more. On Sat, Apr 25, 2015 at 9:52 PM -0700, C. Scott Ananian ecmascr...@cscott.netmailto:ecmascr...@cscott.net wrote: On Sat, Apr 25,

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

Indeed, there is no built-in facility for bundling since as explained in this thread that will actually slow down your performance, and there’s no desire to include an antipattern in the language. From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Eric B Sent: Thursday, April

RE: Putting `global` reference in specs

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

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

From: John Barton [mailto:johnjbar...@google.com] But the push scenario in your first paragraph would not use the cache either. Yeah, that's what I was alluding to with the most naïve comment.   one or the other has to send its information at the outset of a import request, or  One way of

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

Is there any mean in sight, that will allow us to serve them as fast as we can serve hundreds of bundled and minimized CJS modules now? Yes. Any browser which implements the ES6 module loader (none of them right now) will also be a browser that implements HTTP/2 (all of them right now).

Could we make %ArrayPrototype%'s [[DefineOwnProperty]] throw or no-op for numeric keys?

Just an idle thought: Many of the spec-compliance bugs in engines' array implementations over the last couple years have had to do with handling what happens when you e.g. install getters or setters on %ArrayPrototype%. I've been told that handling this case adds lots of complexity to the

RE: the Great Tooling Revolution

This was discussed briefly at the previous meeting, perhaps un-minuted. The basic plan is to develop the spec on GitHub, using [Ecmarkup][] and [Ecmarkdown][]. It will take pull requests, have a master branch that you can view (and implementers should view, to see any bug fixes made since the

RE: the Great Tooling Revolution

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Michael Dyck So not as git branches of the spec? I mean, I guess they could if they want, but that seems like a lot of work for the spec writer to be constantly rebasing. Better to only do the branch when it's time for a

RE: the Great Tooling Revolution

From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com]  However, that is a lot of infrastructure work and I don’t think we should let it to get in the way of shipping our first yearly update. Thanks for pointing this out. I agree that we may be over-optimistic in thinking the new tooling will

RE: Default `this` value for static promise functions

Or just throw: return getError().then(r = { throw r; }) -Original Message- From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Brendan Eich Sent: Tuesday, April 7, 2015 13:47 To: a.d.be...@web.de Cc: es-discuss@mozilla.org Subject: Re: Default `this` value

RE: last value from iterator

I don't think it's good to think of the value sent with `done: true` as one of the values. It's in a different category, and not part of the yielded sequence. From: Mark Volkmannmailto:r.mark.volkm...@gmail.com Sent: ‎2015-‎04-‎05 18:43 To: Allen

RE: Determine if a value is Callable/Constructible

I don’t think [Symbol.call] is a very good mechanism. A new syntactic form would make more sense. It doesn’t seem right that you should have to introduce an observable prototype property just to get [[Call]] behavior. (Or a constructor property, if you change the syntax to `static

RE: Determine if a value is Callable/Constructible

Great to get the ball rolling. Here's some issues I'd bring up at the meeting, so we can get a head start: - As discussed recently in https://esdiscuss.org/topic/reflect-getownpropertysymbols, right now Reflect only holds counterparts to the proxy traps. I think this is kind of a nice

RE: Determine if a value is Callable/Constructible

If you made them non-callable by not implementing [[Call]], then typeof would no longer return function, which would be ... O_o. -Original Message- From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Caitlin Potter Sent: Monday, March 30, 2015 11:25 To: Yehuda Katz

RE: Determine if a value is Callable/Constructible

It could still be identified as a “function” for compat with ES5, but the behaviour is different from any other sort of function, it should be identifiable as different. Right, but again, I don't think the behavior is any different from `function f() { throw new TypeError(); }`, so whatever

RE: Determine if a value is Callable/Constructible

The distinction you're really pointing to here is the distinction between user-generated throwing functions and runtime-generated ones. Both are called. User-generated ones you could edit the source code of and insert a `called = true` line first, whereas runtime-generated ones you could not.

RE: Determine if a value is Callable/Constructible

From: Axel Rauschmayer [mailto:a...@rauschma.de] In some way, that would even be correct – depending on what you expect a function to be: something callable or something constructible. Alas, there is currently no simple way to distinguish “callable” and “constructible”. Why do you say

RE: Determine if a value is Callable/Constructible

From: Kevin Smith [mailto:zenpars...@gmail.com] I'd imagine that you'd re-spec [[Call]] for class constructors to basically do `this[Symbol.call](...args)` instead of just throw.  It would therefore only have an effect within class constructors.  Is that still weird? At least it's

RE: Promises vs Streams

The same argument also implies that arrays are more powerful than scalar values, and we should e.g. never use a number when we could instead just use a single-element array with a number. From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Boopathi Rajaa Sent: Saturday, March

RE: Promises vs Streams

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. It’s also important to realize that streams are not the only asynchronous-plural primitive out there. My

  1   2   3   4   5   6   7   >