Re: Proposal: Improve syntax for inline anonymous class instantiations

> On Jan 6, 2017, at 7:04 PM, Allen Wirfs-Brock wrote: > > (new class extends foo(bar) {…}) > is already valid syntax that means use the value return from calling foo with > argument bar as the superclass of the class that is being instantiated. What > you propose would

Re: Proposal: Improve syntax for inline anonymous class instantiations

(new class extends foo(bar) {…}) is already valid syntax that means use the value return from calling foo with argument bar as the superclass of the class that is being instantiated. What you propose would be a breaking change. ___ es-discuss mailing

Re: Proposal: Improve syntax for inline anonymous class instantiations

For some reason this idea made me think about adding extends to function syntax: ``` class Foo {} function Bar(a, b) extends Foo { // ... } // Basic sugar for function Baz(a, b) { // ... } Object.setPrototypeOf(Baz, Foo); Object.setPrototypeOf(Baz.prototype, Foo.prototype); ``` Although

Proposal: Improve syntax for inline anonymous class instantiations

Given a simple class with an abstract method "populateItem" class ArrayView extends Container { constructor(id, model) { super(id); this.model = model; } // methods referencing "populateItem" omitted for clarity } the current anonymous instantiation syntax looks like

getOwnPropertyDescriptor side effects

That sounds like a bug because error objects are ordinary objects and the [[GetOwnProperty]] internal method of ordinary objects doesn't have side effects. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: getOwnPropertyDescriptor side effects

With the advent of Proxy in ES2015, getOwnPropertyDescriptor can always have side-effects: Object.getOwnPropertyDescriptor(new Proxy({}, { getOwnPropertyDescriptor() { throw "hello world" } }), "foo") On Fri, Jan 6, 2017 at 11:11 AM, Francisco Tolmasky wrote: > Is there any

getOwnPropertyDescriptor side effects

Is there any position on whether getOwnPropertyDescriptor should not have side-effects? I ask because some v8 getOwnPropertyDescriptor *do* have side effects (for example, Object.getOwnPropertyDescriptor(new Error, “stack”) will call Error.prepareStackTrace (it used to not)). Currently I treat

Re: name anonymous functions on property assignments

If no one can remember what the objection was / objections were, I might submit a proposal to close the gap. I'm not a spec expert in any way, but I *think* it's simply a matter of removing the IsIdentifierReference check in Step 1.e of [assignment

Re: Accesssing ES6 class constructor function

> Granted *using* them would be simpler **if** you didn't care whether > you're calling a constructor vs. non-constructor (e.g., you "just" use In ES5 the only thing that makes a constructor behave differently is invoking it with `new`. There's no difference between a constructor and a regular

Re: Accesssing ES6 class constructor function

Note: Related discussion of calling class constructors here: https://esdiscuss.org/topic/determine-if-a-value-is-callable-constructible On Fri, Jan 6, 2017 at 12:11 PM, James Treworgy wrote: > T.J. Thanks for the very thoughtful analysis. But I keep coming back to > this: >

Re: Accesssing ES6 class constructor function

T.J. Thanks for the very thoughtful analysis. But I keep coming back to this: > since we > wouldn't want `call`/`apply` to allow violating the "no `this` before > `super(...)`" rule by setting the `this` binding early. Why? To me the best solution is also the simplest - just let people do this.

Re: Accesssing ES6 class constructor function

On Thu, Jan 5, 2017 at 7:21 PM, James Treworgy wrote: > > Can you clarify what prevents it from being made to work? > > The fundamental feature difference (continuing to think about this!) is that > with ES5 constructors, I can create an instance of something from an abitrary

Re: Resource management

Oh, Bluebird's `Promise.using` does that with very high certainly. The reason we introduced `using` rather than let people just use the disposer pattern is because it is very tricky to get right in userland - so the library provided it. On Fri, Jan 6, 2017 at 2:51 AM, Isiah Meadows