> On Jan 7, 2017, at 4:45 AM, Alexander Jones wrote:
>
> Hi Igor
>
> With `super()` and closure binding of the anonymous class `constructor` (as
> with all class methods) you can basically solve your problem of constructor
> arguments appearing in the wrong place:
>
> ```
> this.add(
> n
Hi Igor
With `super()` and closure binding of the anonymous class `constructor` (as
with all class methods) you can basically solve your problem of constructor
arguments appearing in the wrong place:
```
this.add(
new class extends ArrayView {
constructor() { super("items", itemsModel
Two aspects to this: Motivations and syntax.
## On motivations:
Addressing new syntax, the first question has to be: Is this use case
sufficiently common and painful that it needs new syntax? The answer
may be yes, but we need to ask the question.
Trying to solve it without new syntax with a hel
> 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 be a breaking change.
(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 li
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 n
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
7 matches
Mail list logo
