Re: Promises as Cancelation Tokens

Since checking `promise.state` is synchronous, we may as well just write a synchronous Cancel class instead: ```js class CancelError extends Error { /* ... */ } class Cancel { constructor() { this.requested = false } request() { this.requested = true } throw() { throw new

Re: Promises as Cancelation Tokens

Cool, yeah, the reveal pattern would indeed be a good way to guard against unwanted/unexpected cancels. ```js class Cancel { constructor(executor) { this._requested = false executor(() => this._requested = true) } get requested() {return this._requested} throw() {

Re: [ small request - Javascript for javaing]

> We use it because we have to, not because we like it , so deep down we wish for a more standard language. Nope, I use it because I love it. The language is way better than Java in my opinion (and I have really good experience with both, backend and frontend). Also, telling Python developers to

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

And to answer, the `'k'` in `Object.prototype.toString.call( 'k' )` get auto-boxed. That's why. On Fri, Jan 1, 2016 at 9:29 AM, Domenic Denicola wrote: > This mailing list is largely meant for the further development of > JavaScript as a language (new feature design, spec

Re: ES6 import directive

1) Import is designed for static analysis at compiled time, but that doesn't limit you from implementing a dynamic module loader, as ​kdex pointed out. You can, for example, still use AMD-style define libraries within ES6 Modules if you wish (though I leave that to you to figure out if you really

Re: Automatically giving symbols descriptions

On Fri, Jan 8, 2016 at 9:45 AM, Alexander Jones wrote: > const symbol mySym; > const mySym = Symbol("mySym"); > ​Nice, I like that one.​ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Re[2]: Operators overriding

I'm in favor of no overloading for the reason of the mental tax. People could write a program where everything is a mathematical operation (in looks, not necessarily functionality), which could encourage harder-to-read code. I think `this.plus(that)` is fine for objects. With a proper

Re: Re[2]: Operators overriding

On Mon, Dec 28, 2015 at 10:19 AM, Alexander Jones wrote: > `[] + {}` That's an odd use case. I've never used it myself. Straight face not possible. x] ___ es-discuss mailing list es-discuss@mozilla.org

Re: Re[2]: Operators overriding

onsibility to write good code. Of course you can write bad code with > operation overloading, but you can also write bad code now. > > Regards, > Sander > > > 2015-12-28 19:45 GMT+01:00 /#!/JoePea <j...@trusktr.io>: >> >> I'm kind of on the fence about it. `let resu

Re: Re[2]: Operators overriding

I'm kind of on the fence about it. `let result = matrix1.multiply(matrix2)` works for graphics, but `var result = matrix1 * matrix2` could be nice. Now that I think about it, I think I'll fall over onto the +1 side of the fence, because one of the things I love about JavaScript is how flexible it

Re: Modifying ES6 module exports

iling, or > Webpack with another transpiler? > > > On Mon, Dec 21, 2015 at 7:25 PM, /#!/JoePea <j...@trusktr.io> wrote: >> >> I'm curious, what should happen when module A imports the default from >> module B which imports the default from module A? Should the

Modifying ES6 module exports

I'm curious, what should happen when module A imports the default from module B which imports the default from module A? Should the exported A object exist inside of module B? Here's two modules A and B (simplified from some real code that I have), which have a circular dependency: ```js // A.js

Re: Modifying ES6 module exports

f the module. >> >> all in all, that's what you're experiencing. as for the {}, that's just >> babel. >> >> side note: this has nothing to do with those being default exports, it >> will happen for any export. >> >> /caridy >> >> > On

Re: Re: Add support for arbitrary code inside template tags without the 'do' keyword

The thing with template strings is that they are used at runtime. This could be slow if we're compiling things at runtime all the time, whereas a server-side templating solution might lead JavaScript functions compiled from templates (like in the case with Meteor Blaze Spacebars or React JSX),

Re: Add support for arbitrary code inside template tags without the 'do' keyword

u posted are equivalent (modulo the obvious >> mistake). AFAIU there is still only a single parsing pass for template >> strings. >> >> On Tuesday, 12 January 2016, /#!/JoePea <j...@trusktr.io> wrote: >>> >>> The thing with template strings is that they

Re: Re: Add support for arbitrary code inside template tags without the 'do' keyword

If it's any consolation, you can currently use Babel (f.e with Webpack, Browserify, etc) to compile do-expressions (babeljs.io/docs/plugins/syntax-do-expressions), so you can use the syntax right now. On Sun, Jan 10, 2016 at 11:07 PM, Manuel Di Iorio wrote: > Thanks Caitlin for

Re: Add support for arbitrary code inside template tags without the 'do' keyword

>> http://facebook.github.io/jsx/#why-not-template-literals >> >> >> On Wed, Jan 13, 2016, 05:45 /#!/JoePea <j...@trusktr.io> wrote: >>> >>> > modulo the obvious mistake >>> >>> Oops. x] >>> >>> > you could use

`await null` to stay in the same tick?

I'm not sure where's the best place to ask, but if I ``` await null ``` in an async function does that guarantee that the following code will execute immediately (control flow will not go anywhere else)? - Joe ___ es-discuss mailing list

Re: `await null` to stay in the same tick?

PU-bound work across multiple events. You can explicitly await >> conditionally. >> >> ``` >> if (guard) { await guard; } >> ``` >> > > Good example, thanks. > > > >> >> On Sun, Feb 7, 2016 at 1:39 PM /#!/JoePea <j...@trusktr.io

Re: `await null` to stay in the same tick?

(Or, maybe it's Facebook Regenerator's fault, not Babel's) On Monday, February 8, 2016, /#!/JoePea <j...@trusktr.io> wrote: > Aah, good to know. With Babel this isn't the case, as `await null` doesn't > defer, so I was doing `await somethingThatMightBeNull` to po

Re: monadic extension to do-notation

On Tue, Feb 9, 2016 at 10:28 PM, Isiah Meadows wrote: > let finalPromise = (async () => { > let x = await promiseA > let y = await promiseB > let c = f(a, b) > return g(a, b, c) > })() I think it's important to keep the async/await keywords because they give a

Re: Optional Chaining (aka Existential Operator, Null Propagation)

.?.3` would have to fail as a syntax error. ``` let a = [1,2,{n:1}] console.log(a[2]) // {n:1} console.log(a.?2) // {n:1} console.log(a.?.2) // SyntaxError console.log(a.?2.3) // SyntaxError: Unexpected number (the 3) console.log(a.?2.n) // 1 console.log(a.?2.?n) // 1 ``` /#!/JoePea On Feb 4, 2016

Re: File Type for Module Goal

I don't see a need for it. Module loaders these days can easily distinguish CommonJS modules from ES6 modules (f.e. JSPM.io does that automatically, and so does Webpack and Browserify with plugins). I understand that right now we can't `require` es6 modules using Node's `require` function, but

Re: JavaScript Language feature Idea

I think Symbol.last seems like the best option so far, without breaking things. On Fri, Jan 22, 2016 at 8:44 PM, John Gardner wrote: > Using a well-known symbol to access an array's last element is probably > wiser than a typical method or property: > > let a = [0, 1, 2,

Re: JavaScript Language feature Idea

> [1,2,3](-1) But it implies a function call, which isn't the case. It could possibly be confusing when reading code. On Mon, Jan 25, 2016 at 1:04 PM, Bob Myers wrote: > The syntactical construct `array()` is unused as far as I know, since > currently it would always generate a

Re: JavaScript Language feature Idea

Freedom of choice for the win. I like it. On Sat, Jan 23, 2016 at 12:46 PM, kdex wrote: > @Michał: That really depends on the point of view: If you need zero-based > indexing from the right, as `[]` does from the left, you'd use > `Array.prototype.last`. > > On Samstag, 23. Januar

Re: How to modify the scope chain without `with` ?

But then, you might as well start using modules and properly scoping variables, as that will lend to much more readable code. (Sent again, wrong "from") /#!/JoePea On Feb 16, 2016 7:57 AM, "Coroutines" <corouti...@gmail.com> wrote: > On Tue, Feb 16, 2016 at 7:

Re: How to modify the scope chain without `with` ?

/angular/angular.js/wiki/Understanding-Scopes). /#!/JoePea On Feb 16, 2016 9:10 AM, "/#!/JoePea" <j...@trusktr.io> wrote: > But then, you might as well start using modules and properly scoping > variables, as that will lend to much more readable code. > > (Sent again,

Re: How to modify the scope chain without `with` ?

/#!/JoePea On Feb 16, 2016 9:13 AM, "/#!/JoePea" <j...@trusktr.io> wrote: > > Seems like changing the global could lead to problems where a developer might assumes certain globals but hey I meant: "but have" different ones. Importing things explicitly into modules

Re: How to modify the scope chain without `with` ?

/#!/JoePea On Feb 16, 2016 9:38 AM, "Coroutines" <corouti...@gmail.com> wrote: > > On Tue, Feb 16, 2016 at 9:16 AM, /#!/JoePea <j...@trusktr.io> wrote: > > /#!/JoePea > > On Feb 16, 2016 9:13 AM, "/#!/JoePea" <j...@trusktr.io> wrote: > &g

Re: Destructuring an object into a new object (like Underscore pick but ESier)

Bob, the benefit of your proposed syntax would be that the object identifier comes first instead of last, so the reader can see the intent of the code sooner: ```js let newObj = {...obj.{foo, bar}, quux:4} ``` /#!/JoePea On Feb 19, 2016 9:55 AM, "Bob Myers" <r...@gol.com>

Re: GC/Compile requests, with 3D engine demonstration

> but worried that things could return without calling attemptGC(), That's what the "use scoped-gc" directive would guarantee, it would be like calling attemptGC() (but forceGC), at the end of each function. > That makes messy, spaghetti code, though. Ugly indeed, like using globals.

Re: One-shot Delimited Continuations with Effect Handlers

The effect addition to try-catch seems like some sort of hacky workaround, that would get the job done, but then would make try-catch be used for purposes other than catching errors, which defeats it's original purpose. I think it's important to keep that error-based meaning and not mix it with

Do await statements unblock synchronously?

Is code that follows an await statement supposed to get executed in the same tick in which the statement's awaited promise is resolved? F.e.: ```js let resolve = null const somePromise = new Promise(r => resolve = r) ~async function() { await somePromise doSomething() }() // ... time passes

Re: Do await statements unblock synchronously?

t;>> prove it's not observable. >>> >>> On Mon, Apr 11, 2016 at 9:54 AM, Andrea Giammarchi >>> <andrea.giammar...@gmail.com> wrote: >>>> >>>> > I suppose I'm asking for cases where the await statement's promise is >>>> > u

Re: Do await statements unblock synchronously?

ly yes. Minor issues inline > > On Mon, Apr 11, 2016 at 10:32 PM, /#!/JoePea <j...@trusktr.io> wrote: >> >> So just to clarify, the code following an await statement should never >> run in the tick in which the await statement is executed, should never >>

Re: Proposal: ignored arguments

, undefined, 3 ) ``` Well, if an argument can be undefined like that then there might be bad design there too, IMO. /#!/JoePea On Mar 4, 2016 3:33 AM, "Alan Johnson" <a...@breakrs.com> wrote: > What about something like a bare `.`? Putting nothing there seems a bit > error pr

Re: Object.prototype.forIn

Nice use of generators! I'll save this one into my toolbox. /#!/JoePea On Mar 4, 2016 6:43 PM, "Jordan Harband" <ljh...@gmail.com> wrote: > While I would like a function for this too, this is pretty trivial: > > ``` > function* enumerate(obj) { for (var key i

Promises, async functions, and requestAnimationFrame, together.

Is it possible? I thought maybe something like this: ```js function animationFrame() { let resolve = null const promise = new Promise(r => resolve = r) window.requestAnimationFrame(resolve) return promise } async function game() { // the game loop while (true) {

Re: Pseudo headless arrows

I like that Headless Arrow Function proposal (http://bterlson.github.io/headless-arrows). ```js doSomethingAsync(=> console.log('done')) ``` On Thu, Apr 21, 2016 at 5:02 PM, Michael Theriot wrote: > Three equals used outside of strict equality might take some

Re: Promises, async functions, and requestAnimationFrame, together.

/c28e83cc-0968-11e6-8771-8e726158aa52.png On Sat, Apr 23, 2016 at 3:18 PM, /#!/JoePea <j...@trusktr.io> wrote: > Alright, I did an experiment, and I'm really surprised at the results! > Apparently, the logic (what would be drawSomething() in my previous > example) is fired within the

Re: Promises, async functions, and requestAnimationFrame, together.

Alright, I did an experiment, and I'm really surprised at the results! Apparently, the logic (what would be drawSomething() in my previous example) is fired within the frame!! So, let me show you my original method for starting an animation loop. I'm working on a 3D project at http://infamous.io.

Extending Object

Are the following examples the same? Is there any reason to extend Object manually? ```js class Foo { constructor() {} } new Foo ``` ```js class Foo extends Object { constructor() { super() } // super() is required. } new Foo ``` ___ es-discuss

Re: Is `undefined` garabage collectable?

ly nothing involving > dynamic data structures. > > /Andreas > > > On 5 May 2016 at 07:48, /#!/JoePea <j...@trusktr.io> wrote: > >> > The only v8 shell I have lying around is too old (3.14.5.10) to have >> Set, so I can't tell you what it would do. >

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: 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

Re: "Super" hoisting

gt; if (data === undefined) { > wm.set(this, data = { > a: x + y, > b: ay, > c: bx, > }) > } > return data.c; > } > } > ``` > > > On Fri, May 13, 2016, 13:14 Bri

Re: "Super" hoisting

> let data = wm.get(this) >> if (data === undefined) { >> wm.set(this, data = { >> a: x + y, >> b: ay, >> c: bx, >> }) >> } >> return data.c;

Re: Is `undefined` garabage collectable?

> The only v8 shell I have lying around is too old (3.14.5.10) to have Set, so I can't tell you what it would do. On my first attempt, I noticed 8 Major GCs: https://cloud.githubusercontent.com/assets/297678/15036715/f41ea4d4-1247-11e6-8823-f153c3c1b7bb.png On second attempt, no Major GCs:

Is `undefined` garabage collectable?

For example, I have some code that uses a Map just to keep a collection of things (the keys) but values are not important, so they are undefined, like this: ```js let something = {} let otherThing = {} let m = new Map m.set(something) m.set( ​otherThing​ ) ``` where the values for those object

Re: JavaScript Language feature Idea

Backwards compatibility has been broken before. I don't think this one is too bad of a breakage. On Sun, Apr 17, 2016 at 9:48 PM, Biju wrote: > On 17 April 2016 at 17:29, Frankie Bagnardi wrote: >> That would break backward compatibility; >> >>

Re: JavaScript Language feature Idea

eturn Reflect.set(target, > computeProperty(target, property), receiver); > } > }); > } > } > ``` > > On Montag, 18. April 2016 09:59:15 CEST /#!/JoePea wrote: >> Backwards compatibility has been broken before. I don't think this one >> is too bad of a breakage. >> >> On Sun,

Re: Function#toString revision: JSDoc comments?

I don't believe JSDoc is part of ES spec, right? It could easily be something else. We can not infer types at runtime for many functions in the first place, so what point would the JSDoc have? Consider this example: ```js var f = function(arg1, arg2) { console.log(arg1, arg2) } console.log(f)

Re: JavaScript Language feature Idea

roduce negative array indices in a way that doesn't break >> the web like this: >> >> ```js >> [1, 2, 3][-1]; // undefined >> Array[Symbol.implementation] = MyArray; >> [1, 2, 3][-1]; // 3 >> Array[Symbol.implementation] = 3; // TypeError: Array implem

Why are object initializer methods not usable as constructors?

. */#!/*JoePea ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Redefining a let variable inside a for loop scope doesn't work?

is this not the case? Is it by design, and if so why? */#!/*JoePea ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: The `super` keyword doesn't work as it should?

` like `Function.prototype.with`, so `someFunc.with(homeObject)` returns a new function who's [[HomeObject]] is the specified `homeObject`. It would be possible to do `someFunc.with(...).bind(...)` to configure both the home object and `this`. */#!/*JoePea On Thu, Jul 21, 2016 at 3:21 AM, Claude

Re: Why are object initializer methods not usable as constructors?

why it works the dynamic way if that ever became reality. Plus, if `Function.prototype.toMethod` is brought into spec, then you'd also be technical enough to borrow the method and assign the original HomeObject that you wish. */#!/*JoePea On Wed, Jul 27, 2016 at 11:44 AM, /#!/JoePea <j...@t

Re: The `super` keyword doesn't work as it should?

gle prototype chain in question. It should not even be a concern. */#!/*JoePea On Tue, Jul 19, 2016 at 11:42 PM, Raul-Sebastian Mihăilă < raul.miha...@gmail.com> wrote: > I wasn't suggesting any mechanism for accomplishing that. Method borrowing > is error prone either way. With t

Re: The `super` keyword doesn't work as it should?

new objects are created with `new ctor()` the only way to do it, as far as ES6 class constructors go (I can use `.call(proxy)` on the ES5 constructors)? */#!/*JoePea ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: The `super` keyword doesn't work as it should?

ackwards compatible with how it currently works) along with something like `toMethod`. --- Does anyone mind pointing out the specific unwanted overhead costs of a dynamic `super`? */#!/*JoePea ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Why are object initializer methods not usable as constructors?

extra cost to simply pass that found object by reference to the `foo` method call, since we already found it. That's not very costly. I may be using the word "HomeObject" wrong, but I think you get what I mean. */#!/*JoePea On Thu, Jul 28, 2016 at 9:11 AM, Tab Atkins Jr. <jackalm

How to refer to the current prototype of a class.

} baz() { // .. } } ``` Or a symbol? ```js class Foo { bar() { // we want the current prototype's (HomeObject's?) `baz` method, not the leafmost prototype's (this') `baz` method. #.baz() } baz() { // .. } } ``` */#!/*JoePea ___ es-discu

Re: The `super` keyword doesn't work as it should?

ing to leave this alone for now, and just continue with the class-factory mixin approach, although that is not my ideal solution. Any ideas or suggestions? */#!/*JoePea On Wed, Jul 27, 2016 at 7:51 PM, /#!/JoePea <j...@trusktr.io> wrote: > > 1) There are indeed use cases for dynamica

Re: The `super` keyword doesn't work as it should?

For reference, here's the implementation of `multiple()` where multiple constructors calls are possible, using a `callSuperConstructor` helper: https://gist.github.com/trusktr/05b9c763ac70d7086fe3a08c2c4fb4bf */#!/*JoePea On Wed, Jul 27, 2016 at 8:16 PM, /#!/JoePea <j...@trusktr.io>

Re: The `super` keyword doesn't work as it should?

re fact that a dynamic or configurable `[[HomeObject]]` would allow for the creation of a tool like what I am trying to implement is good enough reason to have the feature. Who knows what other awesome ideas people will come up with. */#!/*JoePea On Sun, Jul 24, 2016 at 7:54 PM, Allen Wirfs-Brock <al.

Re: How to solve this basic ES6-module circular dependency problem?

Are bindings live across all modules at the same time, as if the identifier were defined in an outer scope common to all the modules that import it? */#!/*JoePea ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es

Re: How to solve this basic ES6-module circular dependency problem?

eed a `setUpA` export, especially called by one of its dependencies. Just declare and initialize that crap when it's being declared. That's what I thought at first too, but it's not the case, and I'm trying to find a solution. */#!/*JoePea On Wed, Aug 10, 2016 at 2:41 AM, Isiah Meadows <isiahm

Re: How to solve this basic ES6-module circular dependency problem?

not sure if that is spec'd or not). - Joe */#!/*JoePea On Tue, Aug 9, 2016 at 2:04 PM, Jason Orendorff <jason.orendo...@gmail.com> wrote: > On Tue, Aug 9, 2016 at 3:03 PM, /#!/JoePea <j...@trusktr.io> wrote: > >> Why is it that the body of module C is not evaluated before

Re: How to solve this basic ES6-module circular dependency problem?

Aha, when using my setup functions, rollup.js tries to evaluate C first, in which case the *hoisted* functions are available, but A is not declared yet. I don't think that this would happen in real ES6 modules (no hoisting like that). */#!/*JoePea On Wed, Aug 10, 2016 at 12:55 PM, /#!/JoePea &l

Re: How to solve this basic ES6-module circular dependency problem?

. I'm not sure what the solution is yet though. */#!/*JoePea On Wed, Aug 10, 2016 at 1:06 PM, Bradley Meck <bradley.m...@gmail.com> wrote: > > -- Forwarded message -- > From: Bradley Meck <bradley.m...@gmail.com> > Date: Wed, Aug 10, 2016 at 3:05 PM >

Re: How to solve this basic ES6-module circular dependency problem?

handle properly if I understand live bindings correctly). */#!/*JoePea On Wed, Aug 10, 2016 at 12:31 PM, /#!/JoePea <j...@trusktr.io> wrote: > In your module B, `class B` should `extends C` instead of A, so both > classes `A` and `B` extend from `C`. > > I made a reproductio

Re: How to solve this basic ES6-module circular dependency problem?

example), and as you can see it will evaluate B first in which case C will be undefined and throw an error. Bradley, true, but C is also child of A, so it can also make sense to evaluate C before A. They are children of each other. In that case, what is the correct order of evaluation? */#!/*JoePea

Re: How to solve this basic ES6-module circular dependency problem?

*not* have knowledge of it's subclasses, but the base class in my case is intended to be internal only, not a part of the public API that end users will extend from. */#!/*JoePea On Tue, Aug 9, 2016 at 11:12 PM, /#!/JoePea <j...@trusktr.io> wrote: > I can get the whole thing to work

Re: How to solve this basic ES6-module circular dependency problem?

setUpB(C) console.log('Module C', B) export {C as default} ``` */#!/*JoePea On Tue, Aug 9, 2016 at 9:59 PM, /#!/JoePea <j...@trusktr.io> wrote: > It seems that the environment I'm in (Meteor uses [reify]( > https://github.com/benjamn/reify)) tries to evaluate A and B first, so I

Re: How to solve this basic ES6-module circular dependency problem?

`C.default` is `undefined` because the ES6 modules are compiled into CommonJS form). I thought that if `C` was a live binding, then it should be ready by the time the `setUpA` function is called. Should this in fact be the case? */#!/*JoePea On Tue, Aug 9, 2016 at 5:36 PM, John Lenz <concavel

Re: How to solve this basic ES6-module circular dependency problem?

s import A from './A' import B from './B' console.log(A) console.log(B) } } export {C as default} ``` */#!/*JoePea ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: How to solve this basic ES6-module circular dependency problem?

console.log(A) console.log(B) } } } initC() export {C as default} ``` */#!/*JoePea On Thu, Aug 11, 2016 at 10:26 AM, Logan Smyth <loganfsm...@gmail.com> wrote: > Keep in mind `let A = A;` is a TDZ error in any real ES6 environment. > > The example I posted works proper

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

It seems like `new Symbol()` would be inline with the introduction of classes. Why was it chosen not to be constructible? Seems like it would make sense to throw an error on `Symbol()` but not `new Symbol()`. Was it to save three characters of typing? */#!/*JoePea

Re: How to solve this basic ES6-module circular dependency problem?

g(FOO)` in your console, and you'll get an error because FOO is not defined. Had the bindings been live, then FOO *would* be defined. */#!/*JoePea On Wed, Aug 10, 2016 at 5:04 PM, /#!/JoePea <j...@trusktr.io> wrote: > I found a solution that works in environments compiled by Babe

Re: How to solve this basic ES6-module circular dependency problem?

not work in other ES6 module implementations. Is there some solution that will theoretically work in any ES6 module environment? */#!/*JoePea ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Symbol for modifying property lookup?

reading to get ideas on what I might do, but would love suggestions if you have any. */#!/*JoePea On Wed, Jul 13, 2016 at 3:00 AM, kdex <k...@kdex.de> wrote: > Callable class constructors [1] have been discussed at some point. > They've been withdrawn [2] in favor of decorators

Class expressions in object initializers.

} console.log(o.foo) // logs the class ​```​ */#!/*JoePea ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Class expressions in object initializers.

A use case could be to dynamically name a class at runtime without `eval`. `let o = { [name]() {} }` produces a named function inside of `o` (at least in Chrome) without needing eval, and then we can extract it from the object. */#!/*JoePea On Wed, Jul 13, 2016 at 7:48 PM, Blake Regalia

Re: Symbol for modifying property lookup?

ah() {console.log('yeah')} } let f = new FooBar f.foo() f.bar() f.baz() f.oh() f.yeah() ``` Any ideas on how else to do it? */#!/*JoePea On Tue, Jul 12, 2016 at 1:52 AM, Claude Pache <claude.pa...@gmail.com> wrote: > > Le 12 juil. 2016 à 02:45, /#!/JoePea <j...@trusktr.io> a

The `super` keyword doesn't work as it should?

nt-8. Any ideas or suggestions? */#!/*JoePea ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: The `super` keyword doesn't work as it should?

ance cost of a dynamic super? So far I've read in various places (for example the thread linked to by @medikoo, Axel's 2ality article on super) about there being "overhead", but the articles haven't quantified or put into perspective the actual performance cost. Is it really that

Re: The `super` keyword doesn't work as it should?

, then the first example would work just fine too. */#!/*JoePea On Mon, Jul 18, 2016 at 2:00 PM, /#!/JoePea <j...@trusktr.io> wrote: > For example, both of these examples don't work in Chrome: > > ```js > function A() { > console.log('A') > } > A.prototype.constructor = A >

Re: The `super` keyword doesn't work as it should?

currently works. I wonder what the performance problems are and if they can be solved. */#!/*JoePea On Mon, Jul 18, 2016 at 2:46 PM, Bergi <a.d.be...@web.de> wrote: > /#!/JoePea wrote: > > Why can't `super` simply be a shortcut >> for "look up the prototype of

Re: The `super` keyword doesn't work as it should?

itance: class Node extends multiple(ImperativeBase, TreeNode, Transformable) {} class Scene extends multiple(ImperativeBase, TreeNode) {} ``` */#!/*JoePea On Tue, Jul 19, 2016 at 9:12 AM, Logan Smyth <loganfsm...@gmail.com> wrote: > Joe, it seems like you've focused on `super === &

Re: Redefining a let variable inside a for loop scope doesn't work?

> In a little bit of a handwavy example I imagined a waving hand, holding a piece of chalk with a chalkboard in the background. Thanks for explaining! */#!/*JoePea On Fri, Jul 15, 2016 at 9:31 AM, J Decker <d3c...@gmail.com> wrote: > > > On Fri, Jul 15, 2016 at 7:18 AM, All

Re: Symbol for modifying property lookup?

(this, ...args) ​ // Error, not allowed​ ​Two​ .call(this, ...args)​ // ​Error​ , not allowed ​​ } } ``` */#!/*JoePea On Wed, Jul 13, 2016 at 1:49 AM, /#!/JoePea <j...@trusktr.io> wrote: > Thanks guys, Proxy is the one, but not supported natively enough yet > unfortunately. > > Here i

Symbol for modifying property lookup?

Does one exist? I'm imagining an implementation for ``` class Node extends new MultiClass(ImperativeBase, Transformable) { } ``` */#!/*JoePea ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Symbol for modifying property lookup?

{} // --- extend more than one class: class SomethingElse extends multiple(Foo, Lorem) {} // --- instanceof should work: (new Something) instanceof Lorem // true (new SomethingElse) instanceof Lorem // true ``` I suppose I'll know if it's possible after I try implementing it. :D */#!/*JoePea On Wed

Re: Ambiguity with default exports and live bindings?

at all to make it hard to immediately see what is async and what isn't). */#!/*JoePea On Wed, Jul 6, 2016 at 4:38 PM, Bergi <a.d.be...@web.de> wrote: > /#!/JoePea schrieb: > >> Is it true one of the following does not create a live binding? >> > > Yes and no. >

Ambiguity with default exports and live bindings?

imagine people easily overlooking the difference and expecting live bindings in both cases (this already happened to me). */#!/*JoePea ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Ambiguity with default exports and live bindings?

I think I'm more confused than I thought. Are all bindings read only always, only modifiable by exported functions/classes? */#!/*JoePea On Fri, Jul 8, 2016 at 12:22 PM, /#!/JoePea <j...@trusktr.io> wrote: > Interesting. I think it is very intuitive to think that `export default A

Re: Static `super` may cause a unwanted "memory leak".

Ah, interesting to know. Is such an optimization guaranteed? */#!/*JoePea On Tue, Aug 2, 2016 at 1:59 PM, Jason Orendorff <jason.orendo...@gmail.com> wrote: > On Tue, Aug 2, 2016 at 3:09 PM, Bergi <a.d.be...@web.de> wrote: > >> Why would `tmp` be stored as the [[HomeOb

Re: How to refer to the current prototype of a class.

ch/papers/selective-open-recursion.pdf). */#!/*JoePea ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: How to refer to the current prototype of a class.

med if it were a thing. */#!/*JoePea On Sat, Aug 6, 2016 at 10:20 PM, /#!/JoePea <j...@trusktr.io> wrote: > > On Sun, Jul 31, 2016 at 4:15 AM, Claude Pache <claude.pa...@gmail.com> > wrote: > >> What is the issue with just `Foo.prototype`? > > > ​It means it is sub

  1   2   3   >