Re: extending an ES6 class using ES5 syntax?

I'm trying to provide a path where common code can migrate to ES6 classes before all the consumers have. So I was really looking for something that didn't require the subclasses to be touched at all (I wasn't clear about this). I have a fair amount of control over how the inheritance is setup an

Re: Tracking proposals should be standardized with issues

This entire process is quite unfriendly to grassroots proposals and I hope it can be tweaked. > All proposals that are officially considered by TC39 have to have been submitted in conformance with the Ecma IPR policies including the RF patent policy and the software copyright policy. Is putting

Re: extending an ES6 class using ES5 syntax?

If it's helpful, you can look at how newless handles this: https://github.com/mr0grog/newless/ It's a little more complicated than the earlier replies because many implementations have classes but not `Reflect.construct`, but it goes gracefully allow ES5- function-style constructors to inherit

Re: extending an ES6 class using ES5 syntax?

> > That said, can't the right thing be done using Reflect.construct? > It can: ```js function B() { return Reflect.construct(A, arguments) } ``` `instanceof B` will be `false`, though. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mo

Re: extending an ES6 class using ES5 syntax?

On 5/13/16 9:04 PM, Domenic Denicola wrote: Object.setPrototypeOf(obj, new.target.prototype); // or B.prototype, but if you derive from B you'll have to do this dance again This is highly undesirable because it will deoptimize in implementations in practice. That said, can't the right th

Re: extending an ES6 class using ES5 syntax?

This may be a small bit nicer: ```js class A {} function B() { return Reflect.construct(A, arguments, B) } Reflect.setPrototypeOf(B.prototype, A.prototype) Reflect.setPrototypeOf(B, A) ``` ___ es-discuss mailing list es-discuss@mozilla.org https://mai

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 do

extending an ES6 class using ES5 syntax?

Specifically, I'm looking for a way to call an super class ES6 constructor without violating the "new" rule (TypeError: Class constructor A cannot be invoked without 'new'): class A { } function B() { A.call(this); // this breaks } B.prototype = Object.create(A.prototype); Without something

Re: "Super" hoisting

If we ever get access to GC primitives, I would like to make sure that it is minimally specified. An example of this is that in the JVM standard, `java.lang.System.gc()`'s behavior is completely implementation-defined. Matter of fact, IIRC the standard explicitly mentions that doing nothing is conf

Re: Tracking proposals should be standardized with issues

> On May 12, 2016, at 9:25 PM, G. Kay Lee > wrote: > > Okay, I found a [list of TC39 member > organizations](http://www.ecma-international.org/memento/TC39-RF-TG%20-%20members.htm). > .. > it's hidden in some really ob

Re: "Super" hoisting

> my stuff, you'll see it's pretty free from GC, but that's because I pull a > lot of tricks, which make for messy and hard to understand code. Exactly, which is why standards around GC might help; to prevent the messy brittle code that developers making graphically intense apps will end up writi

Re: "Super" hoisting

It much easier to solve then that, just make a,b,c globals in the class constructor (again, let's consider than objects, not primitives.) If you look at my stuff, you'll see it's pretty free from GC, but that's because I pull a lot of tricks, which make for messy and hard to understand code.

Re: "Super" hoisting

Maybe now that realtime graphically-intensive applications in the web are becoming a thing, there needs to be some sort of standardization on GC so that devs can make meaningful decisions on GC (rather than guessing how to best optimize for different engines and often writing ugly code because of i

Re: Error-Type Specific try/catch Blocks

I offered a few syntaxes for this, perhaps the bitwise OR "|" would be better. On Fri, May 13, 2016 at 1:33 PM, Michał Wadas wrote: > > } catch (await FCL.load(...), await FCL.load(...)) (e) { > Then you have to override comma operator ( > https://developer.mozilla.org/en-US/docs/Web/JavaScript/

Re: "Super" hoisting

I think the original problem that caused this discussion with GC could be solved with just a weak map: ``` // Original class thing { doSomething(x, y) { let a = x + y; let b = ay; let c = bx; return (c); } } // With a weak map const wm = new WeakMap() clas

Re: Error-Type Specific try/catch Blocks

> } catch (await FCL.load(...), await FCL.load(...)) (e) { Then you have to override comma operator ( https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Comma_Operator ) in one specific context... On Fri, May 13, 2016 at 7:14 PM, Joe Groseclose wrote: > @JoePea, that is

Re: introduction of statefull functions (inspired by Scala language) - advanced specification of "operator()" for arbitrary objects

I would like to point out that this particular example could be done in terms of existing proxies now: ```js var sttFunc = new Proxy({}, { get(target, key) { console.log("get: [", key, "]"); return key; }, set(target, key, value) { console.log("set: [", key, "]

Re: Error-Type Specific try/catch Blocks

@JoePea, that is one of the syntaxes I recommend in the proposal. @michalwadas The primary goal of this I think is to create a standard feature, but I do not see why an expression wrapped in parenthesis ultimately resulting in an error class would not be supported. Example: ... } catch (awai

Re: "Super" hoisting

> On May 13, 2016, at 12:13 PM, /#!/JoePea wrote: > > > Or "Cython in Javascript". I think your needs can be satisfied by C/C++ > > addons in Node.js or WebAssembly in browser > > But we want to stay in JavaScript because we like the language. Plus, writing > a framework in JavaScript has the

Re: "Super" hoisting

> On May 13, 2016, at 12:23 PM, Herby Vojčík wrote: > > It's different. Does _allocation_ or _GC_ eats the performance? That’s a good question. It’d be hard to tease out that data for runs of the source, but I suspect it’s GC, because it’s a pause, not an overall slowdown. And over-all paus

Re: Error-Type Specific try/catch Blocks

On 5/13/16 11:06 AM, Joseph Groseclose wrote: I sent this proposal via http://www.ecma-international.org/memento/contribute_TC39_Royalty_Free_Task_Group.php# yesterday evening. Sharing it here now: https://github.com/benderTheCrime/error-type-specific-catch-proposal I'd like to understand the p

Re: Error-Type Specific try/catch Blocks

Perhaps a syntax based on modules: ```js try {} catch (TypeError as e) {} // ... try {} catch (MyError as err) {} ``` On Fri, May 13, 2016 at 9:43 AM, Michał Wadas wrote: > I can't see why would your syntax be superior to SpiderMonkey extension > except saving few characters. > > Can your synt

Re: Error-Type Specific try/catch Blocks

I can't see why would your syntax be superior to SpiderMonkey extension except saving few characters. Can your syntax support code like this: async function foo() { try { throw new Error(); } catch(e if isNativeException(e)) { // special handler for DOM exceptions } catch(e if

Re: "Super" hoisting

On Fri, May 13, 2016 at 4:19 PM, Herby Vojčík wrote: > > > Nicolas B. Pierron wrote: >> >> I do not understand how having local variable should change any GC >> pattern unless you are creating them in the for-loop body. > > > If I understand correctly, the problem is in not reusing the objects. If

Re: "Super" hoisting

On Fri, May 13, 2016 at 4:13 PM, /#!/JoePea wrote: >> I do not understand how having local variable should change any GC pattern >> unless you are creating them in the for-loop body. > > Having locals in a for-loop is the same as having locals in a function that > gets called at 60fps in an animat

Re: "Super" hoisting

I can only tell you what I’ve tested and observed, not sure of the inner workings of any javascript engine. Current alpha of my project is here: http://www.klinksoftware.com/ws/ Recommend latest firefox or chrome. Github link for the code is there. This is

Re: "Super" hoisting

Nicolas B. Pierron wrote: I do not understand how having local variable should change any GC pattern unless you are creating them in the for-loop body. If I understand correctly, the problem is in not reusing the objects. If you do `var x = new X()` in every call of the method, GC should tak

Re: "Super" hoisting

> var x = XPool.get(); I think Brian is saying that local vars are GCed, so that solution doesn't work (creating many local variables at 60fps) > Or "Cython in Javascript". I think your needs can be satisfied by C/C++ addons in Node.js or WebAssembly in browser But we want to stay in JavaScript

Re: "Super" hoisting

> On May 13, 2016, at 11:09 AM, Herby Vojčík wrote: > > > > Brian Barnes wrote: >> It could be, but there is a difference between: >> >> var x; >> >> and: >> >> this.x > > You should probably do `var x = XPool.get();` and at the end `XPool.put(x);` > and do `XPool`s for every possible X ty

Re: "Super" hoisting

Certainly, I’d love webassembly, but as of now, it’s not something that’s part of the spec, or something that I can use right now, and I also want to see how far I can push the language as an experiment. I think there is a place for improving the language as is; it’s surprising how far javascri

Re: Error-Type Specific try/catch Blocks

I've updated the proposal. See: https://github.com/benderTheCrime/error-type-specific-catch-proposal#about-spidermonkey-implementation On Fri, May 13, 2016 at 11:49 AM, Joseph Groseclose wrote: > Nevertheless, perhaps the non-standard implementation could work > hand-in-hand with the proposal, w

Re: Error-Type Specific try/catch Blocks

Nevertheless, perhaps the non-standard implementation could work hand-in-hand with the proposal, where SpiderMonkey could support both solutions in parallel for backward compatibility. I think that the proposed solution is more expressive. On Fri, May 13, 2016 at 11:26 AM, Claude Pache wrote: >

Re: "Super" hoisting

I do not understand how having local variable should change any GC pattern unless you are creating them in the for-loop body. Even though, Scalar Replacement optimizations (which are implemented in all engine?) should be able to remove these allocations once the optimizing JIT is reached, unless th

Re: Error-Type Specific try/catch Blocks

Ah, that does somewhat throw a wrench in the system. I'm not sure what the committee's policy is on backwards compatibility and non-standard features. I find the SpiderMonkey handling you just brought to my attention to be a little clunky. Sent from my iPhone > On May 13, 2016, at 11:26 AM, Cl

Re: "Super" hoisting

It's recurring theme - special syntax to allow/force engines to optimize some code pattern. What do you want is in fact some kind of C. Or "Cython in Javascript". I think your needs can be satisfied by C/C++ addons in Node.js or WebAssembly in browser - it's better to use proper tool rather than t

Re: Error-Type Specific try/catch Blocks

Note that SpiderMonkey has already nonstandard conditional catch clauses: ```js try { // ... } catch (e if e instanceof TypeError) { // } ``` —Claude > Le 13 mai 2016 à 17:06, Joseph Groseclose a écrit : > > I sent this proposal via > http://www.ecma-international.org/memento/co

Re: "Super" hoisting

Brian Barnes wrote: It could be, but there is a difference between: var x; and: this.x You should probably do `var x = XPool.get();` and at the end `XPool.put(x);` and do `XPool`s for every possible X type which you want to not GC. And then happily use local variable, as it should be. If

Error-Type Specific try/catch Blocks

I sent this proposal via http://www.ecma-international.org/memento/contribute_TC39_Royalty_Free_Task_Group.php# yesterday evening. Sharing it here now: https://github.com/benderTheCrime/error-type-specific-catch-proposal ___ es-discuss mailing list es-dis

Re: "Super" hoisting

It could be, but there is a difference between: var x; and: this.x Because you’ll get leakage from the last run, so it would probably be something that would need to be hinted, unless the engine was smart enough to reset everything it hoisted (which is doable) but not optimal, as you might al

Re: "Super" hoisting

Sounds like a potential JS engine optimization, rather than a language feature per se. > On May 12, 2016, at 1:53 PM, Brian Barnes wrote: > > Not by my testing, at least. > > My original example is a simple one to explain what the procedure is. Here’s > a more complex example, from my code,

Re: Tracking proposals should be standardized with issues

As a non-member potential proposer, I'd strongly second this motion. Based on the following: *Ideas for evolving the ECMAScript language are accepted in any form. Any discussion, idea or proposal for a change or addition which has not been submitted as a formal proposal is considered to be a “str