Re: Compiled JS

[J Decker]

Each javascript engine uses different opcodes internally; there is no
universal bytecode like Java, C# or Vulkan.
using closure compiler or some other minification is the closest you can
come; short symbols are quicker to process.

Trying to learn how to do that for V8 Engine, it is possible to generate
precompiled javascript chunks and link them into the compiled product; but
it's not a universal solution, and, as far as I can tell, isn't even really
possible to do into dynamic libraries to add dynamically.


On Tue, Oct 24, 2017 at 10:48 PM, Peter Jaszkowiak 
wrote:

> Compiling JS into an intermediate representation like the JVM or LLVM
> isn't really possible because JavaScript is a dynamic language.
>
> That's my understanding anyways. The binary AST is as close as we can get.
>
> On Oct 24, 2017 23:43, "doodad-js Admin"  wrote:
>
>> No WASM/AST Don’t challenge my ignorance I’m basically suggesting
>> a way to compile:
>>
>>
>>
>> js
>>
>> const a = {};
>>
>> ```
>>
>>
>>
>> to opcodes, like:
>>
>>
>>
>> ```hex
>>
>> F10B6100
>>
>> ```
>>
>>
>>
>> *From:* Karl Cheng [mailto:qantas94he...@gmail.com]
>> *Sent:* Wednesday, October 25, 2017 12:57 AM
>> *To:* doodad-js Admin 
>> *Cc:* es-discuss 
>> *Subject:* Re: Compiled JS
>>
>>
>>
>> It seems that you're referring to something like WebAssembly
>>  or a binary AST
>> . Please check them out
>> and see if they're similar to what you're thinking of.
>>
>>
>>
>> On 25 October 2017 at 08:06, doodad-js Admin  wrote:
>>
>> Hi,
>>
>>
>>
>> By seeing many proposals about reducing the syntax for X and Y, I just
>> want to open the idea of a [non-native] compiled JS world. What do you
>> think?
>>
>>
>>
>> Because, if that’s not the problem (code size), what it is ?
>>
>>
>>
>> Claude Petit
>>
>>
>>
>>
>>
>>
>> 
>>
>> Virus-free. *www.avg.com*
>> 
>>
>>
>> ___
>> es-discuss mailing list
>> *es-discuss@mozilla.org*
>> *https://mail.mozilla.org/listinfo/es-discuss*
>> 
>>
>>
>>
>>
>> --
>> 
>>
>> - Karl Cheng (Qantas94Heavy)
>> 
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Compiled JS

[Peter Jaszkowiak]

Compiling JS into an intermediate representation like the JVM or LLVM isn't
really possible because JavaScript is a dynamic language.

That's my understanding anyways. The binary AST is as close as we can get.

On Oct 24, 2017 23:43, "doodad-js Admin"  wrote:

> No WASM/AST Don’t challenge my ignorance I’m basically suggesting
> a way to compile:
>
>
>
> js
>
> const a = {};
>
> ```
>
>
>
> to opcodes, like:
>
>
>
> ```hex
>
> F10B6100
>
> ```
>
>
>
> *From:* Karl Cheng [mailto:qantas94he...@gmail.com]
> *Sent:* Wednesday, October 25, 2017 12:57 AM
> *To:* doodad-js Admin 
> *Cc:* es-discuss 
> *Subject:* Re: Compiled JS
>
>
>
> It seems that you're referring to something like WebAssembly
>  or a binary AST
> . Please check them out and
> see if they're similar to what you're thinking of.
>
>
>
> On 25 October 2017 at 08:06, doodad-js Admin  wrote:
>
> Hi,
>
>
>
> By seeing many proposals about reducing the syntax for X and Y, I just
> want to open the idea of a [non-native] compiled JS world. What do you
> think?
>
>
>
> Because, if that’s not the problem (code size), what it is ?
>
>
>
> Claude Petit
>
>
>
>
>
>
> 
>
> Virus-free. *www.avg.com*
> 
>
>
> ___
> es-discuss mailing list
> *es-discuss@mozilla.org*
> *https://mail.mozilla.org/listinfo/es-discuss*
> 
>
>
>
>
> --
> 
>
> - Karl Cheng (Qantas94Heavy)
> 
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Compiled JS

[doodad-js Admin]

No WASM/AST Don’t challenge my ignorance I’m basically suggesting a way 
to compile:



js

const a = {};

```



to opcodes, like:



```hex

F10B6100

```



From: Karl Cheng [mailto:qantas94he...@gmail.com]
Sent: Wednesday, October 25, 2017 12:57 AM
To: doodad-js Admin 
Cc: es-discuss 
Subject: Re: Compiled JS



It seems that you're referring to something like WebAssembly 
  or a binary AST 
 . Please check them out and see 
if they're similar to what you're thinking of.



On 25 October 2017 at 08:06, doodad-js Admin mailto:dooda...@gmail.com> > wrote:

Hi,



By seeing many proposals about reducing the syntax for X and Y, I just want to 
open the idea of a [non-native] compiled JS world. What do you think?



Because, if that’s not the problem (code size), what it is ?



Claude Petit






 


 

 Virus-free. www.avg.com 

 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

 



--

 

 - Karl Cheng (Qantas94Heavy)



---
This email has been checked for viruses by AVG.
http://www.avg.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Compiled JS

[Karl Cheng]

It seems that you're referring to something like WebAssembly
 or a binary AST
. Please check them out and
see if they're similar to what you're thinking of.

On 25 October 2017 at 08:06, doodad-js Admin  wrote:

> Hi,
>
>
>
> By seeing many proposals about reducing the syntax for X and Y, I just
> want to open the idea of a [non-native] compiled JS world. What do you
> think?
>
>
>
> Because, if that’s not the problem (code size), what it is ?
>
>
>
> Claude Petit
>
>
>
>
> 
>  Virus-free.
> www.avg.com
> 
> <#m_4873514219324665342_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
- Karl Cheng (Qantas94Heavy)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Compiled JS

[doodad-js Admin]

Not “compile/transpile/... X-language to Javascript “, but compile 
Whatever/Javascript to “operational codes”, or [non-machine level] opcodes. You 
perfectly know what I mean.

From: trus...@gmail.com [mailto:trus...@gmail.com] On Behalf Of /#!/JoePea
Sent: Tuesday, October 24, 2017 5:57 PM
To: doodad-js Admin 
Cc: es-discuss 
Subject: Re: Compiled JS



What do you mean? Like coffeescript?




/#!/JoePea



On Tue, Oct 24, 2017 at 2:06 PM, doodad-js Admin mailto:dooda...@gmail.com> > wrote:

Hi,



By seeing many proposals about reducing the syntax for X and Y, I just want to 
open the idea of a [non-native] compiled JS world. What do you think?



Because, if that’s not the problem (code size), what it is ?



Claude Petit






 


 

 Virus-free. www.avg.com 

 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

 




---
This email has been checked for viruses by AVG.
http://www.avg.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Compiled JS

[/#!/JoePea]

What do you mean? Like coffeescript?

*/#!/*JoePea

On Tue, Oct 24, 2017 at 2:06 PM, doodad-js Admin  wrote:

> Hi,
>
>
>
> By seeing many proposals about reducing the syntax for X and Y, I just
> want to open the idea of a [non-native] compiled JS world. What do you
> think?
>
>
>
> Because, if that’s not the problem (code size), what it is ?
>
>
>
> Claude Petit
>
>
>
>
> 
>  Virus-free.
> www.avg.com
> 
> <#m_-232428727760528994_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Compiled JS

[doodad-js Admin]

Hi,

 

By seeing many proposals about reducing the syntax for X and Y, I just want
to open the idea of a [non-native] compiled JS world. What do you think?

 

Because, if that's not the problem (code size), what it is ?

 

Claude Petit

 



---
This email has been checked for viruses by AVG.
http://www.avg.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object method shorthand after initial declaration

[Jordan Harband]

The following style (although not one I prefer) would have to also work as
a function definition:
```
obj.foo()
{
}
```

On Tue, Oct 24, 2017 at 1:41 PM, /#!/JoePea  wrote:

> `obj.foo() {}` is a syntax error in Chrome, so it seems possible to
> make that a function definition.
> /#!/JoePea
>
>
> On Tue, Oct 24, 2017 at 12:45 PM, Brian Blakely
>  wrote:
> > Is it only valid with a semicolon after `foo()`, though?  Pragma without
> > semicolon throws in three engines.
> >
> > On Tue, Oct 24, 2017 at 2:41 PM, James Kyle  wrote:
> >>
> >> To parse it that way would be changing behavior.
> >>
> >> obj.foo() {}
> >> this.bar() {}
> >>
> >> Are both call expressions followed by a block. They are valid syntaxes
> >> today.
> >>
> >> Think:
> >>
> >> obj.foo();
> >> {
> >> let a = 1;
> >> }
> >>
> >>
> >> On Wed, 25 Oct 2017 at 4:29 am, Brian Blakely  >
> >> wrote:
> >>>
> >>> Extend the method shorthand syntax beyond initial object declaration.
> >>>
> >>> ```js
> >>> const obj = {};
> >>>
> >>> obj.foo() {...}
> >>> ```
> >>>
> >>> Equivalent 2015 syntax:
> >>>
> >>> ```js
> >>> const obj = {
> >>>   foo() {...}
> >>> };
> >>> ```
> >>>
> >>> This is nice for assignment to context:
> >>>
> >>> ```js
> >>> function Foo() {
> >>>   this.bar() {...}
> >>>   this.baz() {...}
> >>> }
> >>>
> >>> const foo = new Foo();
> >>> foo.bar();
> >>> foo.baz();
> >>> ```
> >>>
> >>> Equivalent 2015 syntax:
> >>>
> >>> ```js
> >>> function Foo() {
> >>>   this.bar = function() {...};
> >>>   this.baz = function() {...};
> >>> }
> >>> ```
> >>> ___
> >>> es-discuss mailing list
> >>> es-discuss@mozilla.org
> >>> https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Re: Shorter syntax for arrow function assignment

[doodad-js Admin]

> On its way to being an edge case.



Not really because arrow functions are not re-bindable. They are always bound 
to a single object since their creation. They are meant to be used as “lambda” 
functions”, while providing a workaround for accessing properties of their 
“parent object” (ie the object referred by “this” at their creation). They are 
not simply a shortcut version of “function” like many people thinks.





From: Brian Blakely [mailto:anewpage.me...@gmail.com]
Sent: Tuesday, October 24, 2017 3:39 PM
To: Jordan Harband 
Cc: dante federici ; es-discuss 

Subject: Re: Re: Shorter syntax for arrow function assignment



> normal functions ... remain necessary for any use case where `this` needs to 
> be determined at invocation time.



On its way to being an edge case.



On Tue, Oct 24, 2017 at 2:46 PM, Jordan Harband mailto:ljh...@gmail.com> > wrote:

"ES5 functions" - by which you mean, normal functions - are not "outmoded", 
they remain necessary for any use case where `this` needs to be determined at 
invocation time.



Nothing should ever produce an arrow function without `=>`; and exports 
assuming `const` is an interesting idea, but explicit > implicit, and "typing 
less" is simply not a goal worth optimizing for by itself.



On Tue, Oct 24, 2017 at 11:05 AM, Matthew Robb mailto:matthewwr...@gmail.com> > wrote:

There is practically no gain to suggest this syntax for arrows anyway as a 
module has no this binding you are creating a perpetually contextless function 
whereas using this shorthand syntax for a normal function makes some sense. You 
lose implicit return regardless.






- Matthew Robb



On Tue, Oct 24, 2017 at 1:47 PM, Andrea Giammarchi mailto:andrea.giammar...@gmail.com> > wrote:

> functions are already outmoded



I don't know where you come from but to me:



```js

// this ain't outmoded at all

const obj = {

  method() { return this === obj; }

};



// this ain't outmoded at all

class Any {

  method() { return this instanceof Any; }

}

```



And a module that provides mixins is definitively not outmoded at all

```js

export method() {

  return this !== undefined;

};

```



Omitting the arrow is everything but a syntax win here.



Regards









On Tue, Oct 24, 2017 at 2:32 PM, Brian Blakely mailto:anewpage.me...@gmail.com> > wrote:

At current, sans an explicit assignment, the pragma `foo() {...}` should throw.



On Tue, Oct 24, 2017 at 1:26 PM, dante federici mailto:c.dante.feder...@gmail.com> > wrote:

Another annoying thing JS has to deal with is:

```

// implicitly 'var'

someVar = 10;

```



So, something like:

```

myFn() {

}

```



Would be considered as:

```

var myFn = function() {

}

```



with what semantics exist now. Not best practices, but what is currently 
interpreted in the language.



I'd 100% agree that, as a shorthand, this is nice:

```

myFn() { }

const myFn = () => {}

```



Which is what I mean. But I'm not the full implementation of JavaScript.



___
es-discuss mailing list
es-discuss@mozilla.org 
https://mail.mozilla.org/listinfo/es-discuss




___
es-discuss mailing list
es-discuss@mozilla.org 
https://mail.mozilla.org/listinfo/es-discuss




___
es-discuss mailing list
es-discuss@mozilla.org 
https://mail.mozilla.org/listinfo/es-discuss




___
es-discuss mailing list
es-discuss@mozilla.org 
https://mail.mozilla.org/listinfo/es-discuss




___
es-discuss mailing list
es-discuss@mozilla.org 
https://mail.mozilla.org/listinfo/es-discuss





---
This email has been checked for viruses by AVG.
http://www.avg.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Monkey patching constructors in builtin class hierarchies?

[/#!/JoePea]

I'm not polyfilling Custom Elements, I'm polyfilling something else
that doesn't have the problems that Custom Elements has that makes
them not usable with SVG.
/#!/JoePea


On Tue, Oct 24, 2017 at 12:42 PM, Boris Zbarsky  wrote:
> On 10/24/17 2:03 PM, /#!/JoePea wrote:
>>
>> I was trying to patch `Element` because there's also `SVGElement`
>
>
> For what it's worth, looks like for the moment custom elements has given up
> on the idea of custom non-HTML elements...
>
> -Boris
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object method shorthand after initial declaration

[/#!/JoePea]

`obj.foo() {}` is a syntax error in Chrome, so it seems possible to
make that a function definition.
/#!/JoePea


On Tue, Oct 24, 2017 at 12:45 PM, Brian Blakely
 wrote:
> Is it only valid with a semicolon after `foo()`, though?  Pragma without
> semicolon throws in three engines.
>
> On Tue, Oct 24, 2017 at 2:41 PM, James Kyle  wrote:
>>
>> To parse it that way would be changing behavior.
>>
>> obj.foo() {}
>> this.bar() {}
>>
>> Are both call expressions followed by a block. They are valid syntaxes
>> today.
>>
>> Think:
>>
>> obj.foo();
>> {
>> let a = 1;
>> }
>>
>>
>> On Wed, 25 Oct 2017 at 4:29 am, Brian Blakely 
>> wrote:
>>>
>>> Extend the method shorthand syntax beyond initial object declaration.
>>>
>>> ```js
>>> const obj = {};
>>>
>>> obj.foo() {...}
>>> ```
>>>
>>> Equivalent 2015 syntax:
>>>
>>> ```js
>>> const obj = {
>>>   foo() {...}
>>> };
>>> ```
>>>
>>> This is nice for assignment to context:
>>>
>>> ```js
>>> function Foo() {
>>>   this.bar() {...}
>>>   this.baz() {...}
>>> }
>>>
>>> const foo = new Foo();
>>> foo.bar();
>>> foo.baz();
>>> ```
>>>
>>> Equivalent 2015 syntax:
>>>
>>> ```js
>>> function Foo() {
>>>   this.bar = function() {...};
>>>   this.baz = function() {...};
>>> }
>>> ```
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Shorter syntax for arrow function assignment

[/#!/JoePea]

It doesn't matter if `function`s are being used less, they simply
aren't going away. There's plenty of people specifically relying on
`function` for certain purposes where arrow functions do not work.
Lets avoid getting arrows confused with functions.

```js
const prototype = /* ... get this prototype object from somewhere ... */

prototype.foo = function foo() {
  // do something with `this`.
}
```

That sort of stuff (relying on non-arrows) isn't going away.
/#!/JoePea


On Tue, Oct 24, 2017 at 1:12 PM, Brian Blakely  wrote:
> To be clear, this isn't a proposal to drop support for something.  Don't
> optimize for a fading use-case, however.
>
>>it doesn't seem to add anything other than "I don't like typing '='".
>
> That is absolutely correct, it is a proposal for shorthand syntax.
>
>
> On Tue, Oct 24, 2017 at 4:08 PM, dante federici 
> wrote:
>>
>> The use case fading away doesn't mean you can drop support for it, or that
>> it won't still be in use.
>>
>> Please stop trying to push your "shorthand" syntax of:
>> ```
>> myFn() {
>> }
>> ```
>>
>> It's already been pointed out in multiple cases that:
>> 1. The current usages are not "outmoded"
>> 2. The proposed syntax has misleading `this` binding without the arrow
>> 3. Blocks, ASI, and the object shorthand notation either conflict or make
>> it vague how to interpret
>>
>> This isn't a beneficial syntax moving forward, and it doesn't seem to add
>> anything other than "I don't like typing '='".
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Shorter syntax for arrow function assignment

[Brian Blakely]

To be clear, this isn't a proposal to drop support for something.  Don't
optimize for a fading use-case, however.

>it doesn't seem to add anything other than "I don't like typing '='".

That is absolutely correct, it is a proposal for shorthand syntax.


On Tue, Oct 24, 2017 at 4:08 PM, dante federici 
wrote:

> The use case fading away doesn't mean you can drop support for it, or that
> it won't still be in use.
>
> Please stop trying to push your "shorthand" syntax of:
> ```
> myFn() {
> }
> ```
>
> It's already been pointed out in multiple cases that:
> 1. The current usages are not "outmoded"
> 2. The proposed syntax has misleading `this` binding without the arrow
> 3. Blocks, ASI, and the object shorthand notation either conflict or make
> it vague how to interpret
>
> This isn't a beneficial syntax moving forward, and it doesn't seem to add
> anything other than "I don't like typing '='".
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Shorter syntax for arrow function assignment

[dante federici]

The use case fading away doesn't mean you can drop support for it, or that
it won't still be in use.

Please stop trying to push your "shorthand" syntax of:
```
myFn() {
}
```

It's already been pointed out in multiple cases that:
1. The current usages are not "outmoded"
2. The proposed syntax has misleading `this` binding without the arrow
3. Blocks, ASI, and the object shorthand notation either conflict or make
it vague how to interpret

This isn't a beneficial syntax moving forward, and it doesn't seem to add
anything other than "I don't like typing '='".
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Shorter syntax for arrow function assignment

[Brian Blakely]

This is the case that is fading away (and probably isn't coming back into
vogue ever again):

```js
const Foo = function() {
  this.bar = `b4r`;
};
```


On Tue, Oct 24, 2017 at 1:47 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> > functions are already outmoded
>
> I don't know where you come from but to me:
>
> ```js
> // this ain't outmoded at all
> const obj = {
>   method() { return this === obj; }
> };
>
> // this ain't outmoded at all
> class Any {
>   method() { return this instanceof Any; }
> }
> ```
>
> And a module that provides mixins is definitively not outmoded at all
> ```js
> export method() {
>   return this !== undefined;
> };
> ```
>
> Omitting the arrow is everything but a syntax win here.
>
> Regards
>
>
>
>
> On Tue, Oct 24, 2017 at 2:32 PM, Brian Blakely 
> wrote:
>
>> At current, sans an explicit assignment, the pragma `foo() {...}` should
>> throw.
>>
>> On Tue, Oct 24, 2017 at 1:26 PM, dante federici <
>> c.dante.feder...@gmail.com> wrote:
>>
>>> Another annoying thing JS has to deal with is:
>>> ```
>>> // implicitly 'var'
>>> someVar = 10;
>>> ```
>>>
>>> So, something like:
>>> ```
>>> myFn() {
>>> }
>>> ```
>>>
>>> Would be considered as:
>>> ```
>>> var myFn = function() {
>>> }
>>> ```
>>>
>>> with what semantics exist now. Not best practices, but what is currently
>>> interpreted in the language.
>>>
>>> I'd 100% agree that, as a shorthand, this is nice:
>>> ```
>>> myFn() { }
>>> const myFn = () => {}
>>> ```
>>>
>>> Which is what I mean. But I'm not the full implementation of JavaScript.
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object method shorthand after initial declaration

[Brian Blakely]

Is it only valid with a semicolon after `foo()`, though?  Pragma without
semicolon throws in three engines.

On Tue, Oct 24, 2017 at 2:41 PM, James Kyle  wrote:

> To parse it that way would be changing behavior.
>
> obj.foo() {}
> this.bar() {}
>
> Are both call expressions followed by a block. They are valid syntaxes
> today.
>
> Think:
>
> obj.foo();
> {
> let a = 1;
> }
>
>
> On Wed, 25 Oct 2017 at 4:29 am, Brian Blakely 
> wrote:
>
>> Extend the method shorthand syntax beyond initial object declaration.
>>
>> ```js
>> const obj = {};
>>
>> obj.foo() {...}
>> ```
>>
>> Equivalent 2015 syntax:
>>
>> ```js
>> const obj = {
>>   foo() {...}
>> };
>> ```
>>
>> This is nice for assignment to context:
>>
>> ```js
>> function Foo() {
>>   this.bar() {...}
>>   this.baz() {...}
>> }
>>
>> const foo = new Foo();
>> foo.bar();
>> foo.baz();
>> ```
>>
>> Equivalent 2015 syntax:
>>
>> ```js
>> function Foo() {
>>   this.bar = function() {...};
>>   this.baz = function() {...};
>> }
>> ```
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Monkey patching constructors in builtin class hierarchies?

[Boris Zbarsky]

On 10/24/17 2:03 PM, /#!/JoePea wrote:

I was trying to patch `Element` because there's also `SVGElement`


For what it's worth, looks like for the moment custom elements has given 
up on the idea of custom non-HTML elements...


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Shorter syntax for arrow function assignment

[Brian Blakely]

> normal functions ... remain necessary for any use case where `this` needs
to be determined at invocation time.

On its way to being an edge case.

On Tue, Oct 24, 2017 at 2:46 PM, Jordan Harband  wrote:

> "ES5 functions" - by which you mean, *normal* functions - are not
> "outmoded", they remain necessary for any use case where `this` needs to be
> determined at invocation time.
>
> Nothing should ever produce an arrow function without `=>`; and exports
> assuming `const` is an interesting idea, but explicit > implicit, and
> "typing less" is simply not a goal worth optimizing for by itself.
>
> On Tue, Oct 24, 2017 at 11:05 AM, Matthew Robb 
> wrote:
>
>> There is practically no gain to suggest this syntax for arrows anyway as
>> a module has no this binding you are creating a perpetually contextless
>> function whereas using this shorthand syntax for a normal function makes
>> some sense. You lose implicit return regardless.
>>
>>
>> - Matthew Robb
>>
>> On Tue, Oct 24, 2017 at 1:47 PM, Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>>> > functions are already outmoded
>>>
>>> I don't know where you come from but to me:
>>>
>>> ```js
>>> // this ain't outmoded at all
>>> const obj = {
>>>   method() { return this === obj; }
>>> };
>>>
>>> // this ain't outmoded at all
>>> class Any {
>>>   method() { return this instanceof Any; }
>>> }
>>> ```
>>>
>>> And a module that provides mixins is definitively not outmoded at all
>>> ```js
>>> export method() {
>>>   return this !== undefined;
>>> };
>>> ```
>>>
>>> Omitting the arrow is everything but a syntax win here.
>>>
>>> Regards
>>>
>>>
>>>
>>>
>>> On Tue, Oct 24, 2017 at 2:32 PM, Brian Blakely >> > wrote:
>>>
 At current, sans an explicit assignment, the pragma `foo() {...}`
 should throw.

 On Tue, Oct 24, 2017 at 1:26 PM, dante federici <
 c.dante.feder...@gmail.com> wrote:

> Another annoying thing JS has to deal with is:
> ```
> // implicitly 'var'
> someVar = 10;
> ```
>
> So, something like:
> ```
> myFn() {
> }
> ```
>
> Would be considered as:
> ```
> var myFn = function() {
> }
> ```
>
> with what semantics exist now. Not best practices, but what is
> currently interpreted in the language.
>
> I'd 100% agree that, as a shorthand, this is nice:
> ```
> myFn() { }
> const myFn = () => {}
> ```
>
> Which is what I mean. But I'm not the full implementation of
> JavaScript.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>

 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss


>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Extend Object Dereferencing

[Sebastian Malton]

  I see, I can understand how the currently proposed syntax is more powerful but I can also see people saying that is the base case with only one object it seems weird to have the additional curly bracesSebastian From: r...@gol.comSent: October 24, 2017 3:26 PMTo: sebast...@malton.nameCc: es-discuss@mozilla.orgSubject: Re: Extend Object Dereferencing  If your intent is to say```const a = {b: e.b, c: e.c, d: e.d};```then the reception to such functionality (often referred to as "picking") on this list has been decidedly lukewarm, although I remain mystified why, since IMHO it is a common use case and syntactically straightforward. FWIW the currently proposed syntax is```const a = { {b, c, d} = e };```which allows combining properties from more than one object, as in```const a = { {b, c, d} = e, {g, h, i} = k };```which is equivalent to ```const a = {b: e.b, c: e.c, d: e.d, g: k.g, h: k.h, i: k.i};```BobOn Wed, Oct 25, 2017 at 12:39 AM, Sebastian Malton  wrote:  I guess I do except for the second part```const a = {b, c, d} = e;```   From: r...@gol.comSent: October 24, 2017 3:07 PMTo: sebast...@malton.nameCc: es-discuss@mozilla.orgSubject: Re: Extend Object Dereferencing  Don't you just mean the following:```const {abc, xyz, qnc: {awj}} = obj;```On Wed, Oct 25, 2017 at 12:22 AM, Sebastian Malton  wrote:  This could also be extended to help with cleansing objects.const abc = {cde, def, efg} = obj;Would create an object abc with only those three fields in it.   From: sebast...@malton.nameSent: October 24, 2017 2:51 PMTo: es-discuss@mozilla.orgSubject: Extend Object DereferencingCurrently you can do the following const {abc, xyz, qnc} = obj;However if you want to go more than one level deep then you have to do it again for each level.I therefore propose the ability to do the following const {abc, xyz, qnc.awj} = obj;And this would create the variables 'abc'', 'xyz', 'awj' with the values from obj. If qnc is not present then an undefined dereference exception would be thrown. This could also be extended with the proposed '?.' notation to go even deeper safely.   ___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Extend Object Dereferencing

[Bob Myers]

If your intent is to say

```
const a = {b: e.b, c: e.c, d: e.d};
```

then the reception to such functionality (often referred to as "picking")
on this list has been decidedly lukewarm, although I remain mystified why,
since IMHO it is a common use case and syntactically straightforward. FWIW
the currently proposed syntax is

```
const a = { {b, c, d} = e };
```

which allows combining properties from more than one object, as in

```
const a = { {b, c, d} = e, {g, h, i} = k };
```

which is equivalent to

```
const a = {b: e.b, c: e.c, d: e.d, g: k.g, h: k.h, i: k.i};
```

Bob

On Wed, Oct 25, 2017 at 12:39 AM, Sebastian Malton 
wrote:

> I guess I do except for the second part
>
> ```
> const a = {b, c, d} = e;
> ```
>
> *From:* r...@gol.com
> *Sent:* October 24, 2017 3:07 PM
> *To:* sebast...@malton.name
> *Cc:* es-discuss@mozilla.org
> *Subject:* Re: Extend Object Dereferencing
>
> Don't you just mean the following:
>
> ```
> const {abc, xyz, qnc: {awj}} = obj;
> ```
>
> On Wed, Oct 25, 2017 at 12:22 AM, Sebastian Malton 
> wrote:
>
>> This could also be extended to help with cleansing objects.
>>
>> const abc = {cde, def, efg} = obj;
>>
>> Would create an object abc with only those three fields in it.
>>
>> *From:* sebast...@malton.name
>> *Sent:* October 24, 2017 2:51 PM
>> *To:* es-discuss@mozilla.org
>> *Subject:* Extend Object Dereferencing
>>
>> Currently you can do the following
>>
>> const {abc, xyz, qnc} = obj;
>>
>> However if you want to go more than one level deep then you have to do it
>> again for each level.
>>
>> I therefore propose the ability to do the following
>>
>> const {abc, xyz, qnc.awj} = obj;
>>
>> And this would create the variables 'abc'', 'xyz', 'awj' with the values
>> from obj. If qnc is not present then an undefined dereference exception
>> would be thrown.
>>
>> This could also be extended with the proposed '?.' notation to go even
>> deeper safely.
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Monkey patching constructors in builtin class hierarchies?

[/#!/JoePea]

It's a generic thing to forever impact all future descendants of
Element, in theory. For example, a feature like "Element Behaviors" as
[described here](https://github.com/w3c/webcomponents/issues/662) (but
I'm going to close that one and open a more concise issue with a
working implementation).

The idea is that it would work on any type of element because it is
really generic (just like jQuery works on any type of element), so
patching Element seemed the best way to do it.
/#!/JoePea


On Tue, Oct 24, 2017 at 11:36 AM, Andrea Giammarchi
 wrote:
> are you patching things you know need patching or you want to pollute
> forever the future with your patch?
> Whatever you are doing should not compromise WebGLElement so it's good you
> are unable to patch Element, IMO
>
> On Tue, Oct 24, 2017 at 3:03 PM, /#!/JoePea  wrote:
>>
>> I'm going to use the accessor technique as it's the only way. Thanks!
>>
>> I was trying to patch `Element` because there's also `SVGElement`. I
>> suppose I can duplicate efforts and patch both `HTMLElement` and
>> `SVGElement`; that's not too difficult, but it is conceptually uglier
>> because for example, what if browsers come out with `MathElement`,
>> `WebGLElement`, etc.
>> /#!/JoePea
>>
>>
>> On Tue, Oct 24, 2017 at 10:55 AM, Michał Wadas 
>> wrote:
>> >> To "polyfill" an idea I have for DOM, to propose it later, etc.
>> >
>> > You can consider something like this depending on your needs:
>> > https://gist.github.com/Ginden/03004e52b3d331e236b5256e3b4c08ff
>> >
>> > On Tue, Oct 24, 2017 at 7:47 PM, /#!/JoePea  wrote:
>> >>
>> >> @Michał
>> >>
>> >> > But why do you need this?
>> >>
>> >> To "polyfill" an idea I have for DOM, to propose it later, etc.
>> >>
>> >> @Logan
>> >>
>> >> > Why not store your data separately in a WeakMap and rather than
>> >> > injecting properties onto existing objects? Then you can initialize
>> >> > the
>> >> > stored data on first access of the data you want.
>> >>
>> >> I thought about that, it seems like the only way, but was curious to
>> >> see about the the during-construction way if possible.
>> >>
>> >> @Andrea
>> >>
>> >> But this one doesn't work:
>> >>
>> >> ```js
>> >> window.Element = class extends Element {
>> >>   constructor() {
>> >> super();
>> >> console.log('hello darkness my old friend');
>> >>   }
>> >> };
>> >>
>> >> // then ...
>> >> class MyEl extends HTMLElement {}
>> >> customElements.define('my-el', MyEl);
>> >>
>> >> new MyEl;
>> >> ```
>> >>
>> >> /#!/JoePea
>> >>
>> >>
>> >> On Tue, Oct 24, 2017 at 10:36 AM, Andrea Giammarchi
>> >>  wrote:
>> >> > I know I'm going to regret this already, but since I've secretly
>> >> > played
>> >> > with
>> >> > polyfills, you can still do this:
>> >> >
>> >> > ```js
>> >> > window.HTMLElement = class extends HTMLElement {
>> >> >   constructor() {
>> >> > super();
>> >> > console.log('hello darkness my old friend');
>> >> >   }
>> >> > };
>> >> >
>> >> > // then ...
>> >> > class MyEl extends HTMLElement {}
>> >> > customElements.define('my-el', MyEl);
>> >> >
>> >> > new MyEl;
>> >> > ```
>> >> >
>> >> > Regards
>> >> >
>> >> >
>> >> >
>> >> > On Tue, Oct 24, 2017 at 2:32 PM, Logan Smyth 
>> >> > wrote:
>> >> >>
>> >> >> Given that these are constructors that you don't own, adding your
>> >> >> own
>> >> >> properties to them seems like an overall ugly approach to me. Why
>> >> >> not
>> >> >> store
>> >> >> your data separately in a WeakMap and rather than injecting
>> >> >> properties
>> >> >> onto
>> >> >> existing objects? Then you can initialize the stored data on first
>> >> >> access of
>> >> >> the data you want.
>> >> >>
>> >> >> On Tue, Oct 24, 2017 at 10:25 AM, /#!/JoePea  wrote:
>> >> >>>
>> >> >>> Well, I know I can set accessors on a prototype easily, but what I
>> >> >>> mean is, I need each instance of an `Element` to have exactly one
>> >> >>> instance of something right after construction during the same
>> >> >>> synchronous operation.
>> >> >>>
>> >> >>> For example, if we have an application with a bunch of pre-existing
>> >> >>> Elements that do not extend from any classes of mine, I'd like for
>> >> >>> the
>> >> >>> all to have `foo` properties, so that I can do this:
>> >> >>>
>> >> >>> ```js
>> >> >>> const el = new SomeCustomElementThatWasDefinedCreatedByMe
>> >> >>> console.log(el.foo) // it exists and is specific to the instance,
>> >> >>> not
>> >> >>> a prototype property
>> >> >>>
>> >> >>> // or
>> >> >>>
>> >> >>> const div = document.createElement('div')
>> >> >>> console.log(div.foo) // it exists and is specific to the instance,
>> >> >>> not
>> >> >>> a prototype property
>> >> >>> ```
>> >> >>>
>> >> >>> Can this be done?
>> >> >>> /#!/JoePea
>> >> >>>
>> >> >>>
>> >> >>> On Tue, Oct 24, 2017 at 10:19 AM, /#!/JoePea 
>> >> >>> wrote:
>> >> >>> >> This feels like a problem similar to
>> >> >>> >> https://esdiscuss.org/topic/block-scoped-prototype-extensions
>> >> >>> >
>> >> >>> > @Boris, even if it were scoped, how do we monkey pa

Re: Extend Object Dereferencing

[Sebastian Malton]

  I guess I do except for the second part```const a = {b, c, d} = e;```From: r...@gol.comSent: October 24, 2017 3:07 PMTo: sebast...@malton.nameCc: es-discuss@mozilla.orgSubject: Re: Extend Object Dereferencing  Don't you just mean the following:```const {abc, xyz, qnc: {awj}} = obj;```On Wed, Oct 25, 2017 at 12:22 AM, Sebastian Malton  wrote:  This could also be extended to help with cleansing objects.const abc = {cde, def, efg} = obj;Would create an object abc with only those three fields in it.   From: sebast...@malton.nameSent: October 24, 2017 2:51 PMTo: es-discuss@mozilla.orgSubject: Extend Object DereferencingCurrently you can do the following const {abc, xyz, qnc} = obj;However if you want to go more than one level deep then you have to do it again for each level.I therefore propose the ability to do the following const {abc, xyz, qnc.awj} = obj;And this would create the variables 'abc'', 'xyz', 'awj' with the values from obj. If qnc is not present then an undefined dereference exception would be thrown. This could also be extended with the proposed '?.' notation to go even deeper safely.   ___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Extend Object Dereferencing

[Bob Myers]

Don't you just mean the following:

```
const {abc, xyz, qnc: {awj}} = obj;
```

On Wed, Oct 25, 2017 at 12:22 AM, Sebastian Malton 
wrote:

> This could also be extended to help with cleansing objects.
>
> const abc = {cde, def, efg} = obj;
>
> Would create an object abc with only those three fields in it.
>
> *From:* sebast...@malton.name
> *Sent:* October 24, 2017 2:51 PM
> *To:* es-discuss@mozilla.org
> *Subject:* Extend Object Dereferencing
>
> Currently you can do the following
>
> const {abc, xyz, qnc} = obj;
>
> However if you want to go more than one level deep then you have to do it
> again for each level.
>
> I therefore propose the ability to do the following
>
> const {abc, xyz, qnc.awj} = obj;
>
> And this would create the variables 'abc'', 'xyz', 'awj' with the values
> from obj. If qnc is not present then an undefined dereference exception
> would be thrown.
>
> This could also be extended with the proposed '?.' notation to go even
> deeper safely.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Extend Object Dereferencing

[Sebastian Malton]

  This could also be extended to help with cleansing objects.const abc = {cde, def, efg} = obj;Would create an object abc with only those three fields in it.From: sebast...@malton.nameSent: October 24, 2017 2:51 PMTo: es-discuss@mozilla.orgSubject: Extend Object DereferencingCurrently you can do the following const {abc, xyz, qnc} = obj;However if you want to go more than one level deep then you have to do it again for each level.I therefore propose the ability to do the following const {abc, xyz, qnc.awj} = obj;And this would create the variables 'abc'', 'xyz', 'awj' with the values from obj. If qnc is not present then an undefined dereference exception would be thrown. This could also be extended with the proposed '?.' notation to go even deeper safely.   ___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Extend Object Dereferencing

[Sebastian Malton]

  Currently you can do the following const {abc, xyz, qnc} = obj;However if you want to go more than one level deep then you have to do it again for each level.I therefore propose the ability to do the following const {abc, xyz, qnc.awj} = obj;And this would create the variables 'abc'', 'xyz', 'awj' with the values from obj. If qnc is not present then an undefined dereference exception would be thrown. This could also be extended with the proposed '?.' notation to go even deeper safely.   ___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Are Map with no references and their values with no references GC'd?

[Jordan Harband]

If the Map is collected, all of its keys and values are no longer
referenced by it, so if there were no other references to them, they'd be
collected at some point.

On Tue, Oct 24, 2017 at 11:20 AM, /#!/JoePea  wrote:

> I have a `WeakMap` whose values are `Map` instances. The values of all
> the `Map`s inside the `WeakMap` are `object`s. If references to keys
> of the `WeakMap` are lost and therefore those items removed from the
> `WeakMap`, will the `Map`s' values be GC'd if there are no references
> to the Maps or to the Map values.
>
> I'm intuitively assuming "yes", but just want to confirm that I don't
> have to explicitly removed everything from the `Map`s manually first.
>
> /#!/JoePea
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Shorter syntax for arrow function assignment

[Jordan Harband]

"ES5 functions" - by which you mean, *normal* functions - are not
"outmoded", they remain necessary for any use case where `this` needs to be
determined at invocation time.

Nothing should ever produce an arrow function without `=>`; and exports
assuming `const` is an interesting idea, but explicit > implicit, and
"typing less" is simply not a goal worth optimizing for by itself.

On Tue, Oct 24, 2017 at 11:05 AM, Matthew Robb 
wrote:

> There is practically no gain to suggest this syntax for arrows anyway as a
> module has no this binding you are creating a perpetually contextless
> function whereas using this shorthand syntax for a normal function makes
> some sense. You lose implicit return regardless.
>
>
> - Matthew Robb
>
> On Tue, Oct 24, 2017 at 1:47 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> > functions are already outmoded
>>
>> I don't know where you come from but to me:
>>
>> ```js
>> // this ain't outmoded at all
>> const obj = {
>>   method() { return this === obj; }
>> };
>>
>> // this ain't outmoded at all
>> class Any {
>>   method() { return this instanceof Any; }
>> }
>> ```
>>
>> And a module that provides mixins is definitively not outmoded at all
>> ```js
>> export method() {
>>   return this !== undefined;
>> };
>> ```
>>
>> Omitting the arrow is everything but a syntax win here.
>>
>> Regards
>>
>>
>>
>>
>> On Tue, Oct 24, 2017 at 2:32 PM, Brian Blakely 
>> wrote:
>>
>>> At current, sans an explicit assignment, the pragma `foo() {...}` should
>>> throw.
>>>
>>> On Tue, Oct 24, 2017 at 1:26 PM, dante federici <
>>> c.dante.feder...@gmail.com> wrote:
>>>
 Another annoying thing JS has to deal with is:
 ```
 // implicitly 'var'
 someVar = 10;
 ```

 So, something like:
 ```
 myFn() {
 }
 ```

 Would be considered as:
 ```
 var myFn = function() {
 }
 ```

 with what semantics exist now. Not best practices, but what is
 currently interpreted in the language.

 I'd 100% agree that, as a shorthand, this is nice:
 ```
 myFn() { }
 const myFn = () => {}
 ```

 Which is what I mean. But I'm not the full implementation of JavaScript.

 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss


>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object method shorthand after initial declaration

[James Kyle]

To parse it that way would be changing behavior.

obj.foo() {}
this.bar() {}

Are both call expressions followed by a block. They are valid syntaxes
today.

Think:

obj.foo();
{
let a = 1;
}


On Wed, 25 Oct 2017 at 4:29 am, Brian Blakely 
wrote:

> Extend the method shorthand syntax beyond initial object declaration.
>
> ```js
> const obj = {};
>
> obj.foo() {...}
> ```
>
> Equivalent 2015 syntax:
>
> ```js
> const obj = {
>   foo() {...}
> };
> ```
>
> This is nice for assignment to context:
>
> ```js
> function Foo() {
>   this.bar() {...}
>   this.baz() {...}
> }
>
> const foo = new Foo();
> foo.bar();
> foo.baz();
> ```
>
> Equivalent 2015 syntax:
>
> ```js
> function Foo() {
>   this.bar = function() {...};
>   this.baz = function() {...};
> }
> ```
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Monkey patching constructors in builtin class hierarchies?

[Andrea Giammarchi]

are you patching things you know need patching or you want to pollute
forever the future with your patch?
Whatever you are doing should not compromise WebGLElement so it's good you
are unable to patch Element, IMO

On Tue, Oct 24, 2017 at 3:03 PM, /#!/JoePea  wrote:

> I'm going to use the accessor technique as it's the only way. Thanks!
>
> I was trying to patch `Element` because there's also `SVGElement`. I
> suppose I can duplicate efforts and patch both `HTMLElement` and
> `SVGElement`; that's not too difficult, but it is conceptually uglier
> because for example, what if browsers come out with `MathElement`,
> `WebGLElement`, etc.
> /#!/JoePea
>
>
> On Tue, Oct 24, 2017 at 10:55 AM, Michał Wadas 
> wrote:
> >> To "polyfill" an idea I have for DOM, to propose it later, etc.
> >
> > You can consider something like this depending on your needs:
> > https://gist.github.com/Ginden/03004e52b3d331e236b5256e3b4c08ff
> >
> > On Tue, Oct 24, 2017 at 7:47 PM, /#!/JoePea  wrote:
> >>
> >> @Michał
> >>
> >> > But why do you need this?
> >>
> >> To "polyfill" an idea I have for DOM, to propose it later, etc.
> >>
> >> @Logan
> >>
> >> > Why not store your data separately in a WeakMap and rather than
> >> > injecting properties onto existing objects? Then you can initialize
> the
> >> > stored data on first access of the data you want.
> >>
> >> I thought about that, it seems like the only way, but was curious to
> >> see about the the during-construction way if possible.
> >>
> >> @Andrea
> >>
> >> But this one doesn't work:
> >>
> >> ```js
> >> window.Element = class extends Element {
> >>   constructor() {
> >> super();
> >> console.log('hello darkness my old friend');
> >>   }
> >> };
> >>
> >> // then ...
> >> class MyEl extends HTMLElement {}
> >> customElements.define('my-el', MyEl);
> >>
> >> new MyEl;
> >> ```
> >>
> >> /#!/JoePea
> >>
> >>
> >> On Tue, Oct 24, 2017 at 10:36 AM, Andrea Giammarchi
> >>  wrote:
> >> > I know I'm going to regret this already, but since I've secretly
> played
> >> > with
> >> > polyfills, you can still do this:
> >> >
> >> > ```js
> >> > window.HTMLElement = class extends HTMLElement {
> >> >   constructor() {
> >> > super();
> >> > console.log('hello darkness my old friend');
> >> >   }
> >> > };
> >> >
> >> > // then ...
> >> > class MyEl extends HTMLElement {}
> >> > customElements.define('my-el', MyEl);
> >> >
> >> > new MyEl;
> >> > ```
> >> >
> >> > Regards
> >> >
> >> >
> >> >
> >> > On Tue, Oct 24, 2017 at 2:32 PM, Logan Smyth 
> >> > wrote:
> >> >>
> >> >> Given that these are constructors that you don't own, adding your own
> >> >> properties to them seems like an overall ugly approach to me. Why not
> >> >> store
> >> >> your data separately in a WeakMap and rather than injecting
> properties
> >> >> onto
> >> >> existing objects? Then you can initialize the stored data on first
> >> >> access of
> >> >> the data you want.
> >> >>
> >> >> On Tue, Oct 24, 2017 at 10:25 AM, /#!/JoePea  wrote:
> >> >>>
> >> >>> Well, I know I can set accessors on a prototype easily, but what I
> >> >>> mean is, I need each instance of an `Element` to have exactly one
> >> >>> instance of something right after construction during the same
> >> >>> synchronous operation.
> >> >>>
> >> >>> For example, if we have an application with a bunch of pre-existing
> >> >>> Elements that do not extend from any classes of mine, I'd like for
> the
> >> >>> all to have `foo` properties, so that I can do this:
> >> >>>
> >> >>> ```js
> >> >>> const el = new SomeCustomElementThatWasDefinedCreatedByMe
> >> >>> console.log(el.foo) // it exists and is specific to the instance,
> not
> >> >>> a prototype property
> >> >>>
> >> >>> // or
> >> >>>
> >> >>> const div = document.createElement('div')
> >> >>> console.log(div.foo) // it exists and is specific to the instance,
> not
> >> >>> a prototype property
> >> >>> ```
> >> >>>
> >> >>> Can this be done?
> >> >>> /#!/JoePea
> >> >>>
> >> >>>
> >> >>> On Tue, Oct 24, 2017 at 10:19 AM, /#!/JoePea 
> wrote:
> >> >>> >> This feels like a problem similar to
> >> >>> >> https://esdiscuss.org/topic/block-scoped-prototype-extensions
> >> >>> >
> >> >>> > @Boris, even if it were scoped, how do we monkey patch a
> >> >>> > *constructor*? By the way, for some reason your link to
> >> >>> > `https://esdiscuss.org/topic/block-scoped-prototype-extensions`
> >> >>> > posted
> >> >>> > as `https://esdiscuss.org/topic/block` which is 404. If you can
> edit
> >> >>> > it it would help others not to stumble on a broken link.
> >> >>> >
> >> >>> >> if that would be possible, then everyone could just monkey patch
> >> >>> >> Object, right?
> >> >>> >
> >> >>> > But everyone can monkey patch the entire class already, aside from
> >> >>> > the
> >> >>> > constructor, by modifying the prototype. Obviously if someone
> >> >>> > returns
> >> >>> > something new from the constructor they might break everything,
> but
> >> >>> > it
> >> >>> > will be completely obvious 

Are Map with no references and their values with no references GC'd?

[/#!/JoePea]

I have a `WeakMap` whose values are `Map` instances. The values of all
the `Map`s inside the `WeakMap` are `object`s. If references to keys
of the `WeakMap` are lost and therefore those items removed from the
`WeakMap`, will the `Map`s' values be GC'd if there are no references
to the Maps or to the Map values.

I'm intuitively assuming "yes", but just want to confirm that I don't
have to explicitly removed everything from the `Map`s manually first.

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

Re: Re: Shorter syntax for arrow function assignment

[Matthew Robb]

There is practically no gain to suggest this syntax for arrows anyway as a
module has no this binding you are creating a perpetually contextless
function whereas using this shorthand syntax for a normal function makes
some sense. You lose implicit return regardless.


- Matthew Robb

On Tue, Oct 24, 2017 at 1:47 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> > functions are already outmoded
>
> I don't know where you come from but to me:
>
> ```js
> // this ain't outmoded at all
> const obj = {
>   method() { return this === obj; }
> };
>
> // this ain't outmoded at all
> class Any {
>   method() { return this instanceof Any; }
> }
> ```
>
> And a module that provides mixins is definitively not outmoded at all
> ```js
> export method() {
>   return this !== undefined;
> };
> ```
>
> Omitting the arrow is everything but a syntax win here.
>
> Regards
>
>
>
>
> On Tue, Oct 24, 2017 at 2:32 PM, Brian Blakely 
> wrote:
>
>> At current, sans an explicit assignment, the pragma `foo() {...}` should
>> throw.
>>
>> On Tue, Oct 24, 2017 at 1:26 PM, dante federici <
>> c.dante.feder...@gmail.com> wrote:
>>
>>> Another annoying thing JS has to deal with is:
>>> ```
>>> // implicitly 'var'
>>> someVar = 10;
>>> ```
>>>
>>> So, something like:
>>> ```
>>> myFn() {
>>> }
>>> ```
>>>
>>> Would be considered as:
>>> ```
>>> var myFn = function() {
>>> }
>>> ```
>>>
>>> with what semantics exist now. Not best practices, but what is currently
>>> interpreted in the language.
>>>
>>> I'd 100% agree that, as a shorthand, this is nice:
>>> ```
>>> myFn() { }
>>> const myFn = () => {}
>>> ```
>>>
>>> Which is what I mean. But I'm not the full implementation of JavaScript.
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Monkey patching constructors in builtin class hierarchies?

[/#!/JoePea]

I'm going to use the accessor technique as it's the only way. Thanks!

I was trying to patch `Element` because there's also `SVGElement`. I
suppose I can duplicate efforts and patch both `HTMLElement` and
`SVGElement`; that's not too difficult, but it is conceptually uglier
because for example, what if browsers come out with `MathElement`,
`WebGLElement`, etc.
/#!/JoePea


On Tue, Oct 24, 2017 at 10:55 AM, Michał Wadas  wrote:
>> To "polyfill" an idea I have for DOM, to propose it later, etc.
>
> You can consider something like this depending on your needs:
> https://gist.github.com/Ginden/03004e52b3d331e236b5256e3b4c08ff
>
> On Tue, Oct 24, 2017 at 7:47 PM, /#!/JoePea  wrote:
>>
>> @Michał
>>
>> > But why do you need this?
>>
>> To "polyfill" an idea I have for DOM, to propose it later, etc.
>>
>> @Logan
>>
>> > Why not store your data separately in a WeakMap and rather than
>> > injecting properties onto existing objects? Then you can initialize the
>> > stored data on first access of the data you want.
>>
>> I thought about that, it seems like the only way, but was curious to
>> see about the the during-construction way if possible.
>>
>> @Andrea
>>
>> But this one doesn't work:
>>
>> ```js
>> window.Element = class extends Element {
>>   constructor() {
>> super();
>> console.log('hello darkness my old friend');
>>   }
>> };
>>
>> // then ...
>> class MyEl extends HTMLElement {}
>> customElements.define('my-el', MyEl);
>>
>> new MyEl;
>> ```
>>
>> /#!/JoePea
>>
>>
>> On Tue, Oct 24, 2017 at 10:36 AM, Andrea Giammarchi
>>  wrote:
>> > I know I'm going to regret this already, but since I've secretly played
>> > with
>> > polyfills, you can still do this:
>> >
>> > ```js
>> > window.HTMLElement = class extends HTMLElement {
>> >   constructor() {
>> > super();
>> > console.log('hello darkness my old friend');
>> >   }
>> > };
>> >
>> > // then ...
>> > class MyEl extends HTMLElement {}
>> > customElements.define('my-el', MyEl);
>> >
>> > new MyEl;
>> > ```
>> >
>> > Regards
>> >
>> >
>> >
>> > On Tue, Oct 24, 2017 at 2:32 PM, Logan Smyth 
>> > wrote:
>> >>
>> >> Given that these are constructors that you don't own, adding your own
>> >> properties to them seems like an overall ugly approach to me. Why not
>> >> store
>> >> your data separately in a WeakMap and rather than injecting properties
>> >> onto
>> >> existing objects? Then you can initialize the stored data on first
>> >> access of
>> >> the data you want.
>> >>
>> >> On Tue, Oct 24, 2017 at 10:25 AM, /#!/JoePea  wrote:
>> >>>
>> >>> Well, I know I can set accessors on a prototype easily, but what I
>> >>> mean is, I need each instance of an `Element` to have exactly one
>> >>> instance of something right after construction during the same
>> >>> synchronous operation.
>> >>>
>> >>> For example, if we have an application with a bunch of pre-existing
>> >>> Elements that do not extend from any classes of mine, I'd like for the
>> >>> all to have `foo` properties, so that I can do this:
>> >>>
>> >>> ```js
>> >>> const el = new SomeCustomElementThatWasDefinedCreatedByMe
>> >>> console.log(el.foo) // it exists and is specific to the instance, not
>> >>> a prototype property
>> >>>
>> >>> // or
>> >>>
>> >>> const div = document.createElement('div')
>> >>> console.log(div.foo) // it exists and is specific to the instance, not
>> >>> a prototype property
>> >>> ```
>> >>>
>> >>> Can this be done?
>> >>> /#!/JoePea
>> >>>
>> >>>
>> >>> On Tue, Oct 24, 2017 at 10:19 AM, /#!/JoePea  wrote:
>> >>> >> This feels like a problem similar to
>> >>> >> https://esdiscuss.org/topic/block-scoped-prototype-extensions
>> >>> >
>> >>> > @Boris, even if it were scoped, how do we monkey patch a
>> >>> > *constructor*? By the way, for some reason your link to
>> >>> > `https://esdiscuss.org/topic/block-scoped-prototype-extensions`
>> >>> > posted
>> >>> > as `https://esdiscuss.org/topic/block` which is 404. If you can edit
>> >>> > it it would help others not to stumble on a broken link.
>> >>> >
>> >>> >> if that would be possible, then everyone could just monkey patch
>> >>> >> Object, right?
>> >>> >
>> >>> > But everyone can monkey patch the entire class already, aside from
>> >>> > the
>> >>> > constructor, by modifying the prototype. Obviously if someone
>> >>> > returns
>> >>> > something new from the constructor they might break everything, but
>> >>> > it
>> >>> > will be completely obvious and people then won't do that. The same
>> >>> > applies with methods and properties, it is super easy to break
>> >>> > entire
>> >>> > applications monkey patching methods.
>> >>> >
>> >>> > ---
>> >>> >
>> >>> > So suppose I want to "polyfill" a concept. For example, I want all
>> >>> > elements to have a new "foo" accessor after they've been
>> >>> > constructed.
>> >>> > Or for example, suppose `HTMLElement.prototype.style` and
>> >>> > `SVGElement.prototype.style` didn't exist yet. How would I patch
>> >>> > those
>> >>> > in?
>> >>> > /#!/JoePea
>> >>>

Re: Monkey patching constructors in builtin class hierarchies?

[Michał Wadas]

> To "polyfill" an idea I have for DOM, to propose it later, etc.

You can consider something like this depending on your needs:
https://gist.github.com/Ginden/03004e52b3d331e236b5256e3b4c08ff

On Tue, Oct 24, 2017 at 7:47 PM, /#!/JoePea  wrote:

> @Michał
>
> > But why do you need this?
>
> To "polyfill" an idea I have for DOM, to propose it later, etc.
>
> @Logan
>
> > Why not store your data separately in a WeakMap and rather than
> injecting properties onto existing objects? Then you can initialize the
> stored data on first access of the data you want.
>
> I thought about that, it seems like the only way, but was curious to
> see about the the during-construction way if possible.
>
> @Andrea
>
> But this one doesn't work:
>
> ```js
> window.Element = class extends Element {
>   constructor() {
> super();
> console.log('hello darkness my old friend');
>   }
> };
>
> // then ...
> class MyEl extends HTMLElement {}
> customElements.define('my-el', MyEl);
>
> new MyEl;
> ```
>
> /#!/JoePea
>
>
> On Tue, Oct 24, 2017 at 10:36 AM, Andrea Giammarchi
>  wrote:
> > I know I'm going to regret this already, but since I've secretly played
> with
> > polyfills, you can still do this:
> >
> > ```js
> > window.HTMLElement = class extends HTMLElement {
> >   constructor() {
> > super();
> > console.log('hello darkness my old friend');
> >   }
> > };
> >
> > // then ...
> > class MyEl extends HTMLElement {}
> > customElements.define('my-el', MyEl);
> >
> > new MyEl;
> > ```
> >
> > Regards
> >
> >
> >
> > On Tue, Oct 24, 2017 at 2:32 PM, Logan Smyth 
> wrote:
> >>
> >> Given that these are constructors that you don't own, adding your own
> >> properties to them seems like an overall ugly approach to me. Why not
> store
> >> your data separately in a WeakMap and rather than injecting properties
> onto
> >> existing objects? Then you can initialize the stored data on first
> access of
> >> the data you want.
> >>
> >> On Tue, Oct 24, 2017 at 10:25 AM, /#!/JoePea  wrote:
> >>>
> >>> Well, I know I can set accessors on a prototype easily, but what I
> >>> mean is, I need each instance of an `Element` to have exactly one
> >>> instance of something right after construction during the same
> >>> synchronous operation.
> >>>
> >>> For example, if we have an application with a bunch of pre-existing
> >>> Elements that do not extend from any classes of mine, I'd like for the
> >>> all to have `foo` properties, so that I can do this:
> >>>
> >>> ```js
> >>> const el = new SomeCustomElementThatWasDefinedCreatedByMe
> >>> console.log(el.foo) // it exists and is specific to the instance, not
> >>> a prototype property
> >>>
> >>> // or
> >>>
> >>> const div = document.createElement('div')
> >>> console.log(div.foo) // it exists and is specific to the instance, not
> >>> a prototype property
> >>> ```
> >>>
> >>> Can this be done?
> >>> /#!/JoePea
> >>>
> >>>
> >>> On Tue, Oct 24, 2017 at 10:19 AM, /#!/JoePea  wrote:
> >>> >> This feels like a problem similar to
> >>> >> https://esdiscuss.org/topic/block-scoped-prototype-extensions
> >>> >
> >>> > @Boris, even if it were scoped, how do we monkey patch a
> >>> > *constructor*? By the way, for some reason your link to
> >>> > `https://esdiscuss.org/topic/block-scoped-prototype-extensions`
> posted
> >>> > as `https://esdiscuss.org/topic/block` which is 404. If you can edit
> >>> > it it would help others not to stumble on a broken link.
> >>> >
> >>> >> if that would be possible, then everyone could just monkey patch
> >>> >> Object, right?
> >>> >
> >>> > But everyone can monkey patch the entire class already, aside from
> the
> >>> > constructor, by modifying the prototype. Obviously if someone returns
> >>> > something new from the constructor they might break everything, but
> it
> >>> > will be completely obvious and people then won't do that. The same
> >>> > applies with methods and properties, it is super easy to break entire
> >>> > applications monkey patching methods.
> >>> >
> >>> > ---
> >>> >
> >>> > So suppose I want to "polyfill" a concept. For example, I want all
> >>> > elements to have a new "foo" accessor after they've been constructed.
> >>> > Or for example, suppose `HTMLElement.prototype.style` and
> >>> > `SVGElement.prototype.style` didn't exist yet. How would I patch
> those
> >>> > in?
> >>> > /#!/JoePea
> >>> >
> >>> >
> >>> > On Tue, Oct 24, 2017 at 10:07 AM, Michał Wadas <
> michalwa...@gmail.com>
> >>> > wrote:
> >>> >> AFAIR DOM classes are not extensible by any means.
> >>> >>
> >>> >>
> >>> >>
> >>> >> On 24 Oct 2017 6:51 pm, "/#!/JoePea"  wrote:
> >>> >>>
> >>> >>> Is it possible to monkey-patch an intermediate constructor of a
> >>> >>> built-in
> >>> >>> subclass?
> >>> >>>
> >>> >>> For example, suppose I want all `Element` instances in a web app to
> >>> >>> have
> >>> >>> new instance properties, is there a way to monkey-patch the Element
> >>> >>> constructor so that when I make a custom element by extending a
> >>> >>> subclas

Re: Monkey patching constructors in builtin class hierarchies?

[Boris Zbarsky]

On 10/24/17 12:50 PM, /#!/JoePea wrote:
Is it possible to monkey-patch an intermediate constructor of a built-in 
subclass?


Right now, no.

For example, suppose I want all `Element` instances in a web app to have 
new instance properties, is there a way to monkey-patch the Element 
constructor so that when I make a custom element by extending a subclass 
of `Element` that the new logic will fire?


If you want to limit this to custom elements you control, in the sense 
of , then 
"sort of, yes".  You could just define a class that extends HTMLElement, 
have its constructor do whatever instance-property-setting you want, and 
have all your actual custom element classes extend that one class.


If you want to do this to custom elements you do NOT control, you can 
sort of do it too, using Andrea's suggestion later in this thread: as 
long as your code runs first, you can set your class as 
window.HTMLElement so everyone else is extending you, not the "real" 
HTMLElement.



const OldElement = window.Element


This won't work, because Element is not constructible, so all the 
constructor behavior lives in HTMLElement.  But if you did this with 
HTMLElement, I would expect it would work, as in Andrea's suggestion.


Is there a way to monkey patch a constructor in the middle of a built-in 
prototype chain or to otherwise inject construction logic to base 
classes of existing class hierarchies?


Right now, no.

-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Monkey patching constructors in builtin class hierarchies?

[/#!/JoePea]

@Michał

> But why do you need this?

To "polyfill" an idea I have for DOM, to propose it later, etc.

@Logan

> Why not store your data separately in a WeakMap and rather than injecting 
> properties onto existing objects? Then you can initialize the stored data on 
> first access of the data you want.

I thought about that, it seems like the only way, but was curious to
see about the the during-construction way if possible.

@Andrea

But this one doesn't work:

```js
window.Element = class extends Element {
  constructor() {
super();
console.log('hello darkness my old friend');
  }
};

// then ...
class MyEl extends HTMLElement {}
customElements.define('my-el', MyEl);

new MyEl;
```

/#!/JoePea


On Tue, Oct 24, 2017 at 10:36 AM, Andrea Giammarchi
 wrote:
> I know I'm going to regret this already, but since I've secretly played with
> polyfills, you can still do this:
>
> ```js
> window.HTMLElement = class extends HTMLElement {
>   constructor() {
> super();
> console.log('hello darkness my old friend');
>   }
> };
>
> // then ...
> class MyEl extends HTMLElement {}
> customElements.define('my-el', MyEl);
>
> new MyEl;
> ```
>
> Regards
>
>
>
> On Tue, Oct 24, 2017 at 2:32 PM, Logan Smyth  wrote:
>>
>> Given that these are constructors that you don't own, adding your own
>> properties to them seems like an overall ugly approach to me. Why not store
>> your data separately in a WeakMap and rather than injecting properties onto
>> existing objects? Then you can initialize the stored data on first access of
>> the data you want.
>>
>> On Tue, Oct 24, 2017 at 10:25 AM, /#!/JoePea  wrote:
>>>
>>> Well, I know I can set accessors on a prototype easily, but what I
>>> mean is, I need each instance of an `Element` to have exactly one
>>> instance of something right after construction during the same
>>> synchronous operation.
>>>
>>> For example, if we have an application with a bunch of pre-existing
>>> Elements that do not extend from any classes of mine, I'd like for the
>>> all to have `foo` properties, so that I can do this:
>>>
>>> ```js
>>> const el = new SomeCustomElementThatWasDefinedCreatedByMe
>>> console.log(el.foo) // it exists and is specific to the instance, not
>>> a prototype property
>>>
>>> // or
>>>
>>> const div = document.createElement('div')
>>> console.log(div.foo) // it exists and is specific to the instance, not
>>> a prototype property
>>> ```
>>>
>>> Can this be done?
>>> /#!/JoePea
>>>
>>>
>>> On Tue, Oct 24, 2017 at 10:19 AM, /#!/JoePea  wrote:
>>> >> This feels like a problem similar to
>>> >> https://esdiscuss.org/topic/block-scoped-prototype-extensions
>>> >
>>> > @Boris, even if it were scoped, how do we monkey patch a
>>> > *constructor*? By the way, for some reason your link to
>>> > `https://esdiscuss.org/topic/block-scoped-prototype-extensions` posted
>>> > as `https://esdiscuss.org/topic/block` which is 404. If you can edit
>>> > it it would help others not to stumble on a broken link.
>>> >
>>> >> if that would be possible, then everyone could just monkey patch
>>> >> Object, right?
>>> >
>>> > But everyone can monkey patch the entire class already, aside from the
>>> > constructor, by modifying the prototype. Obviously if someone returns
>>> > something new from the constructor they might break everything, but it
>>> > will be completely obvious and people then won't do that. The same
>>> > applies with methods and properties, it is super easy to break entire
>>> > applications monkey patching methods.
>>> >
>>> > ---
>>> >
>>> > So suppose I want to "polyfill" a concept. For example, I want all
>>> > elements to have a new "foo" accessor after they've been constructed.
>>> > Or for example, suppose `HTMLElement.prototype.style` and
>>> > `SVGElement.prototype.style` didn't exist yet. How would I patch those
>>> > in?
>>> > /#!/JoePea
>>> >
>>> >
>>> > On Tue, Oct 24, 2017 at 10:07 AM, Michał Wadas 
>>> > wrote:
>>> >> AFAIR DOM classes are not extensible by any means.
>>> >>
>>> >>
>>> >>
>>> >> On 24 Oct 2017 6:51 pm, "/#!/JoePea"  wrote:
>>> >>>
>>> >>> Is it possible to monkey-patch an intermediate constructor of a
>>> >>> built-in
>>> >>> subclass?
>>> >>>
>>> >>> For example, suppose I want all `Element` instances in a web app to
>>> >>> have
>>> >>> new instance properties, is there a way to monkey-patch the Element
>>> >>> constructor so that when I make a custom element by extending a
>>> >>> subclass of
>>> >>> `Element` that the new logic will fire?
>>> >>>
>>> >>> For example:
>>> >>>
>>> >>> ```js
>>> >>> // monkey-patch the Element constructor somehow so that it logs
>>> >>> "patched
>>> >>> in Element".
>>> >>>
>>> >>> // then
>>> >>> class FooBar extends HTMLElement {}
>>> >>> customElement.define('foo-bar', FooBar)
>>> >>> new FooBar // "patched in Element"
>>> >>> ```
>>> >>>
>>> >>> I tried
>>> >>>
>>> >>> ```js
>>> >>> const OldElement = window.Element
>>> >>>
>>> >>> window.Element = function Element() {
>>> >>>   const _this = new Old

Re: Re: Shorter syntax for arrow function assignment

[Andrea Giammarchi]

> functions are already outmoded

I don't know where you come from but to me:

```js
// this ain't outmoded at all
const obj = {
  method() { return this === obj; }
};

// this ain't outmoded at all
class Any {
  method() { return this instanceof Any; }
}
```

And a module that provides mixins is definitively not outmoded at all
```js
export method() {
  return this !== undefined;
};
```

Omitting the arrow is everything but a syntax win here.

Regards




On Tue, Oct 24, 2017 at 2:32 PM, Brian Blakely 
wrote:

> At current, sans an explicit assignment, the pragma `foo() {...}` should
> throw.
>
> On Tue, Oct 24, 2017 at 1:26 PM, dante federici <
> c.dante.feder...@gmail.com> wrote:
>
>> Another annoying thing JS has to deal with is:
>> ```
>> // implicitly 'var'
>> someVar = 10;
>> ```
>>
>> So, something like:
>> ```
>> myFn() {
>> }
>> ```
>>
>> Would be considered as:
>> ```
>> var myFn = function() {
>> }
>> ```
>>
>> with what semantics exist now. Not best practices, but what is currently
>> interpreted in the language.
>>
>> I'd 100% agree that, as a shorthand, this is nice:
>> ```
>> myFn() { }
>> const myFn = () => {}
>> ```
>>
>> Which is what I mean. But I'm not the full implementation of JavaScript.
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Since we're discussing arrow functions and syntax...

[dante federici]

I'd check out the bind and pipe operators:
https://github.com/tc39/proposal-bind-operator
https://github.com/tc39/proposal-pipeline-operator

But my problems are `=>` and `->` would really lead to some sadness.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Since we're discussing arrow functions and syntax...

[Andrea Giammarchi]

I was for it before ES6 and they told me it was "an arrow too far"

however, object methods shortcuts are better than arrows and methods is the
only place where you need `this`

On Tue, Oct 24, 2017 at 2:34 PM, kai zhu  wrote:

> -1
> this is user-hostile to c++ programmers writing wasm / node-native
> modules, when they context-switch c++ <-> javascript
>
> On 10/25/17, Michael Rosefield  wrote:
> > I like arrow functions, and sometimes the only reason I don't use them is
> > because I need this-binding.
> >
> > So I, personally would like a variant that uses the CoffeeScript ->
> syntax
> > that is precisely like => except that it uses traditional this-binding.
> The
> > only 2 issues I can see are:
> >
> > * adding more syntax to the language
> > * could the concise form bind this? Would, say `const foo = obj ->
> > Object.assign(obj, this.bar)` work, if then used, say, as follows: `const
> > baz = { bar: { /*whatever*/ } }; foo.call(baz, { /* something */ })`
> >
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Monkey patching constructors in builtin class hierarchies?

[Andrea Giammarchi]

I know I'm going to regret this already, but since I've secretly played
with polyfills, you can still do this:

```js
window.HTMLElement = class extends HTMLElement {
  constructor() {
super();
console.log('hello darkness my old friend');
  }
};

// then ...
class MyEl extends HTMLElement {}
customElements.define('my-el', MyEl);

new MyEl;
```

Regards



On Tue, Oct 24, 2017 at 2:32 PM, Logan Smyth  wrote:

> Given that these are constructors that you don't own, adding your own
> properties to them seems like an overall ugly approach to me. Why not store
> your data separately in a WeakMap and rather than injecting properties onto
> existing objects? Then you can initialize the stored data on first access
> of the data you want.
>
> On Tue, Oct 24, 2017 at 10:25 AM, /#!/JoePea  wrote:
>
>> Well, I know I can set accessors on a prototype easily, but what I
>> mean is, I need each instance of an `Element` to have exactly one
>> instance of something right after construction during the same
>> synchronous operation.
>>
>> For example, if we have an application with a bunch of pre-existing
>> Elements that do not extend from any classes of mine, I'd like for the
>> all to have `foo` properties, so that I can do this:
>>
>> ```js
>> const el = new SomeCustomElementThatWasDefinedCreatedByMe
>> console.log(el.foo) // it exists and is specific to the instance, not
>> a prototype property
>>
>> // or
>>
>> const div = document.createElement('div')
>> console.log(div.foo) // it exists and is specific to the instance, not
>> a prototype property
>> ```
>>
>> Can this be done?
>> /#!/JoePea
>>
>>
>> On Tue, Oct 24, 2017 at 10:19 AM, /#!/JoePea  wrote:
>> >> This feels like a problem similar to https://esdiscuss.org/topic/bl
>> ock-scoped-prototype-extensions
>> >
>> > @Boris, even if it were scoped, how do we monkey patch a
>> > *constructor*? By the way, for some reason your link to
>> > `https://esdiscuss.org/topic/block-scoped-prototype-extensions`
>>  posted
>> > as `https://esdiscuss.org/topic/block`
>>  which is 404. If you can edit
>> > it it would help others not to stumble on a broken link.
>> >
>> >> if that would be possible, then everyone could just monkey patch
>> Object, right?
>> >
>> > But everyone can monkey patch the entire class already, aside from the
>> > constructor, by modifying the prototype. Obviously if someone returns
>> > something new from the constructor they might break everything, but it
>> > will be completely obvious and people then won't do that. The same
>> > applies with methods and properties, it is super easy to break entire
>> > applications monkey patching methods.
>> >
>> > ---
>> >
>> > So suppose I want to "polyfill" a concept. For example, I want all
>> > elements to have a new "foo" accessor after they've been constructed.
>> > Or for example, suppose `HTMLElement.prototype.style` and
>> > `SVGElement.prototype.style` didn't exist yet. How would I patch those
>> > in?
>> > /#!/JoePea
>> >
>> >
>> > On Tue, Oct 24, 2017 at 10:07 AM, Michał Wadas 
>> wrote:
>> >> AFAIR DOM classes are not extensible by any means.
>> >>
>> >>
>> >>
>> >> On 24 Oct 2017 6:51 pm, "/#!/JoePea"  wrote:
>> >>>
>> >>> Is it possible to monkey-patch an intermediate constructor of a
>> built-in
>> >>> subclass?
>> >>>
>> >>> For example, suppose I want all `Element` instances in a web app to
>> have
>> >>> new instance properties, is there a way to monkey-patch the Element
>> >>> constructor so that when I make a custom element by extending a
>> subclass of
>> >>> `Element` that the new logic will fire?
>> >>>
>> >>> For example:
>> >>>
>> >>> ```js
>> >>> // monkey-patch the Element constructor somehow so that it logs
>> "patched
>> >>> in Element".
>> >>>
>> >>> // then
>> >>> class FooBar extends HTMLElement {}
>> >>> customElement.define('foo-bar', FooBar)
>> >>> new FooBar // "patched in Element"
>> >>> ```
>> >>>
>> >>> I tried
>> >>>
>> >>> ```js
>> >>> const OldElement = window.Element
>> >>>
>> >>> window.Element = function Element() {
>> >>>   const _this = new OldElement
>> >>>   console.log("patched in Element")
>> >>>   return _this
>> >>> }
>> >>>
>> >>> window.Element.prototype = OldElement.prototype
>> >>> window.Element.prototype.constructor = window.Element
>> >>>
>> >>> class FooBar extends HTMLElement {}
>> >>> customElements.define('f-b', FooBar)
>> >>> new FooBar // does not log "patched in Element"
>> >>> ```
>> >>>
>> >>> But when I make a new custom element, constructing it seems to use
>> the old
>> >>> Element constructor, as if a non-global reference to the original
>> >>> constructor is kept inside a module so that modifying the global
>> wouldn't
>> >>> have any effect.
>> >>>
>> >>> Is there a way to monkey patch a constructor in the middle of a
>> built-in
>> >>> prototype chain or to otherwise inject construction logic to base
>> classes of
>> >>> existing class 

Re: Since we're discussing arrow functions and syntax...

[kai zhu]

-1
this is user-hostile to c++ programmers writing wasm / node-native
modules, when they context-switch c++ <-> javascript

On 10/25/17, Michael Rosefield  wrote:
> I like arrow functions, and sometimes the only reason I don't use them is
> because I need this-binding.
>
> So I, personally would like a variant that uses the CoffeeScript -> syntax
> that is precisely like => except that it uses traditional this-binding. The
> only 2 issues I can see are:
>
> * adding more syntax to the language
> * could the concise form bind this? Would, say `const foo = obj ->
> Object.assign(obj, this.bar)` work, if then used, say, as follows: `const
> baz = { bar: { /*whatever*/ } }; foo.call(baz, { /* something */ })`
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Shorter syntax for arrow function assignment

[Brian Blakely]

At current, sans an explicit assignment, the pragma `foo() {...}` should
throw.

On Tue, Oct 24, 2017 at 1:26 PM, dante federici 
wrote:

> Another annoying thing JS has to deal with is:
> ```
> // implicitly 'var'
> someVar = 10;
> ```
>
> So, something like:
> ```
> myFn() {
> }
> ```
>
> Would be considered as:
> ```
> var myFn = function() {
> }
> ```
>
> with what semantics exist now. Not best practices, but what is currently
> interpreted in the language.
>
> I'd 100% agree that, as a shorthand, this is nice:
> ```
> myFn() { }
> const myFn = () => {}
> ```
>
> Which is what I mean. But I'm not the full implementation of JavaScript.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Monkey patching constructors in builtin class hierarchies?

[Logan Smyth]

Given that these are constructors that you don't own, adding your own
properties to them seems like an overall ugly approach to me. Why not store
your data separately in a WeakMap and rather than injecting properties onto
existing objects? Then you can initialize the stored data on first access
of the data you want.

On Tue, Oct 24, 2017 at 10:25 AM, /#!/JoePea  wrote:

> Well, I know I can set accessors on a prototype easily, but what I
> mean is, I need each instance of an `Element` to have exactly one
> instance of something right after construction during the same
> synchronous operation.
>
> For example, if we have an application with a bunch of pre-existing
> Elements that do not extend from any classes of mine, I'd like for the
> all to have `foo` properties, so that I can do this:
>
> ```js
> const el = new SomeCustomElementThatWasDefinedCreatedByMe
> console.log(el.foo) // it exists and is specific to the instance, not
> a prototype property
>
> // or
>
> const div = document.createElement('div')
> console.log(div.foo) // it exists and is specific to the instance, not
> a prototype property
> ```
>
> Can this be done?
> /#!/JoePea
>
>
> On Tue, Oct 24, 2017 at 10:19 AM, /#!/JoePea  wrote:
> >> This feels like a problem similar to https://esdiscuss.org/topic/
> block-scoped-prototype-extensions
> >
> > @Boris, even if it were scoped, how do we monkey patch a
> > *constructor*? By the way, for some reason your link to
> > `https://esdiscuss.org/topic/block-scoped-prototype-extensions` posted
> > as `https://esdiscuss.org/topic/block` which is 404. If you can edit
> > it it would help others not to stumble on a broken link.
> >
> >> if that would be possible, then everyone could just monkey patch
> Object, right?
> >
> > But everyone can monkey patch the entire class already, aside from the
> > constructor, by modifying the prototype. Obviously if someone returns
> > something new from the constructor they might break everything, but it
> > will be completely obvious and people then won't do that. The same
> > applies with methods and properties, it is super easy to break entire
> > applications monkey patching methods.
> >
> > ---
> >
> > So suppose I want to "polyfill" a concept. For example, I want all
> > elements to have a new "foo" accessor after they've been constructed.
> > Or for example, suppose `HTMLElement.prototype.style` and
> > `SVGElement.prototype.style` didn't exist yet. How would I patch those
> > in?
> > /#!/JoePea
> >
> >
> > On Tue, Oct 24, 2017 at 10:07 AM, Michał Wadas 
> wrote:
> >> AFAIR DOM classes are not extensible by any means.
> >>
> >>
> >>
> >> On 24 Oct 2017 6:51 pm, "/#!/JoePea"  wrote:
> >>>
> >>> Is it possible to monkey-patch an intermediate constructor of a
> built-in
> >>> subclass?
> >>>
> >>> For example, suppose I want all `Element` instances in a web app to
> have
> >>> new instance properties, is there a way to monkey-patch the Element
> >>> constructor so that when I make a custom element by extending a
> subclass of
> >>> `Element` that the new logic will fire?
> >>>
> >>> For example:
> >>>
> >>> ```js
> >>> // monkey-patch the Element constructor somehow so that it logs
> "patched
> >>> in Element".
> >>>
> >>> // then
> >>> class FooBar extends HTMLElement {}
> >>> customElement.define('foo-bar', FooBar)
> >>> new FooBar // "patched in Element"
> >>> ```
> >>>
> >>> I tried
> >>>
> >>> ```js
> >>> const OldElement = window.Element
> >>>
> >>> window.Element = function Element() {
> >>>   const _this = new OldElement
> >>>   console.log("patched in Element")
> >>>   return _this
> >>> }
> >>>
> >>> window.Element.prototype = OldElement.prototype
> >>> window.Element.prototype.constructor = window.Element
> >>>
> >>> class FooBar extends HTMLElement {}
> >>> customElements.define('f-b', FooBar)
> >>> new FooBar // does not log "patched in Element"
> >>> ```
> >>>
> >>> But when I make a new custom element, constructing it seems to use the
> old
> >>> Element constructor, as if a non-global reference to the original
> >>> constructor is kept inside a module so that modifying the global
> wouldn't
> >>> have any effect.
> >>>
> >>> Is there a way to monkey patch a constructor in the middle of a
> built-in
> >>> prototype chain or to otherwise inject construction logic to base
> classes of
> >>> existing class hierarchies?
> >>>
> >>>
> >>> /#!/JoePea
> >>>
> >>> ___
> >>> es-discuss mailing list
> >>> es-discuss@mozilla.org
> >>> https://mail.mozilla.org/listinfo/es-discuss
> >>>
> >>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Monkey patching constructors in builtin class hierarchies?

[Michał Wadas]

You can use getters mutating an object for this task.

But why do you need this?

On 24 Oct 2017 7:25 pm, "/#!/JoePea"  wrote:

> Well, I know I can set accessors on a prototype easily, but what I
> mean is, I need each instance of an `Element` to have exactly one
> instance of something right after construction during the same
> synchronous operation.
>
> For example, if we have an application with a bunch of pre-existing
> Elements that do not extend from any classes of mine, I'd like for the
> all to have `foo` properties, so that I can do this:
>
> ```js
> const el = new SomeCustomElementThatWasDefinedCreatedByMe
> console.log(el.foo) // it exists and is specific to the instance, not
> a prototype property
>
> // or
>
> const div = document.createElement('div')
> console.log(div.foo) // it exists and is specific to the instance, not
> a prototype property
> ```
>
> Can this be done?
> /#!/JoePea
>
>
> On Tue, Oct 24, 2017 at 10:19 AM, /#!/JoePea  wrote:
> >> This feels like a problem similar to https://esdiscuss.org/topic/
> block-scoped-prototype-extensions
> >
> > @Boris, even if it were scoped, how do we monkey patch a
> > *constructor*? By the way, for some reason your link to
> > `https://esdiscuss.org/topic/block-scoped-prototype-extensions` posted
> > as `https://esdiscuss.org/topic/block` which is 404. If you can edit
> > it it would help others not to stumble on a broken link.
> >
> >> if that would be possible, then everyone could just monkey patch
> Object, right?
> >
> > But everyone can monkey patch the entire class already, aside from the
> > constructor, by modifying the prototype. Obviously if someone returns
> > something new from the constructor they might break everything, but it
> > will be completely obvious and people then won't do that. The same
> > applies with methods and properties, it is super easy to break entire
> > applications monkey patching methods.
> >
> > ---
> >
> > So suppose I want to "polyfill" a concept. For example, I want all
> > elements to have a new "foo" accessor after they've been constructed.
> > Or for example, suppose `HTMLElement.prototype.style` and
> > `SVGElement.prototype.style` didn't exist yet. How would I patch those
> > in?
> > /#!/JoePea
> >
> >
> > On Tue, Oct 24, 2017 at 10:07 AM, Michał Wadas 
> wrote:
> >> AFAIR DOM classes are not extensible by any means.
> >>
> >>
> >>
> >> On 24 Oct 2017 6:51 pm, "/#!/JoePea"  wrote:
> >>>
> >>> Is it possible to monkey-patch an intermediate constructor of a
> built-in
> >>> subclass?
> >>>
> >>> For example, suppose I want all `Element` instances in a web app to
> have
> >>> new instance properties, is there a way to monkey-patch the Element
> >>> constructor so that when I make a custom element by extending a
> subclass of
> >>> `Element` that the new logic will fire?
> >>>
> >>> For example:
> >>>
> >>> ```js
> >>> // monkey-patch the Element constructor somehow so that it logs
> "patched
> >>> in Element".
> >>>
> >>> // then
> >>> class FooBar extends HTMLElement {}
> >>> customElement.define('foo-bar', FooBar)
> >>> new FooBar // "patched in Element"
> >>> ```
> >>>
> >>> I tried
> >>>
> >>> ```js
> >>> const OldElement = window.Element
> >>>
> >>> window.Element = function Element() {
> >>>   const _this = new OldElement
> >>>   console.log("patched in Element")
> >>>   return _this
> >>> }
> >>>
> >>> window.Element.prototype = OldElement.prototype
> >>> window.Element.prototype.constructor = window.Element
> >>>
> >>> class FooBar extends HTMLElement {}
> >>> customElements.define('f-b', FooBar)
> >>> new FooBar // does not log "patched in Element"
> >>> ```
> >>>
> >>> But when I make a new custom element, constructing it seems to use the
> old
> >>> Element constructor, as if a non-global reference to the original
> >>> constructor is kept inside a module so that modifying the global
> wouldn't
> >>> have any effect.
> >>>
> >>> Is there a way to monkey patch a constructor in the middle of a
> built-in
> >>> prototype chain or to otherwise inject construction logic to base
> classes of
> >>> existing class hierarchies?
> >>>
> >>>
> >>> /#!/JoePea
> >>>
> >>> ___
> >>> es-discuss mailing list
> >>> es-discuss@mozilla.org
> >>> https://mail.mozilla.org/listinfo/es-discuss
> >>>
> >>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Object method shorthand after initial declaration

[Brian Blakely]

Extend the method shorthand syntax beyond initial object declaration.

```js
const obj = {};

obj.foo() {...}
```

Equivalent 2015 syntax:

```js
const obj = {
  foo() {...}
};
```

This is nice for assignment to context:

```js
function Foo() {
  this.bar() {...}
  this.baz() {...}
}

const foo = new Foo();
foo.bar();
foo.baz();
```

Equivalent 2015 syntax:

```js
function Foo() {
  this.bar = function() {...};
  this.baz = function() {...};
}
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Since we're discussing arrow functions and syntax...

[Michael Rosefield]

I like arrow functions, and sometimes the only reason I don't use them is
because I need this-binding.

So I, personally would like a variant that uses the CoffeeScript -> syntax
that is precisely like => except that it uses traditional this-binding. The
only 2 issues I can see are:

* adding more syntax to the language
* could the concise form bind this? Would, say `const foo = obj ->
Object.assign(obj, this.bar)` work, if then used, say, as follows: `const
baz = { bar: { /*whatever*/ } }; foo.call(baz, { /* something */ })`
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Shorter syntax for arrow function assignment

[dante federici]

Another annoying thing JS has to deal with is:
```
// implicitly 'var'
someVar = 10;
```

So, something like:
```
myFn() {
}
```

Would be considered as:
```
var myFn = function() {
}
```

with what semantics exist now. Not best practices, but what is currently
interpreted in the language.

I'd 100% agree that, as a shorthand, this is nice:
```
myFn() { }
const myFn = () => {}
```

Which is what I mean. But I'm not the full implementation of JavaScript.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Monkey patching constructors in builtin class hierarchies?

[/#!/JoePea]

Well, I know I can set accessors on a prototype easily, but what I
mean is, I need each instance of an `Element` to have exactly one
instance of something right after construction during the same
synchronous operation.

For example, if we have an application with a bunch of pre-existing
Elements that do not extend from any classes of mine, I'd like for the
all to have `foo` properties, so that I can do this:

```js
const el = new SomeCustomElementThatWasDefinedCreatedByMe
console.log(el.foo) // it exists and is specific to the instance, not
a prototype property

// or

const div = document.createElement('div')
console.log(div.foo) // it exists and is specific to the instance, not
a prototype property
```

Can this be done?
/#!/JoePea


On Tue, Oct 24, 2017 at 10:19 AM, /#!/JoePea  wrote:
>> This feels like a problem similar to 
>> https://esdiscuss.org/topic/block-scoped-prototype-extensions
>
> @Boris, even if it were scoped, how do we monkey patch a
> *constructor*? By the way, for some reason your link to
> `https://esdiscuss.org/topic/block-scoped-prototype-extensions` posted
> as `https://esdiscuss.org/topic/block` which is 404. If you can edit
> it it would help others not to stumble on a broken link.
>
>> if that would be possible, then everyone could just monkey patch Object, 
>> right?
>
> But everyone can monkey patch the entire class already, aside from the
> constructor, by modifying the prototype. Obviously if someone returns
> something new from the constructor they might break everything, but it
> will be completely obvious and people then won't do that. The same
> applies with methods and properties, it is super easy to break entire
> applications monkey patching methods.
>
> ---
>
> So suppose I want to "polyfill" a concept. For example, I want all
> elements to have a new "foo" accessor after they've been constructed.
> Or for example, suppose `HTMLElement.prototype.style` and
> `SVGElement.prototype.style` didn't exist yet. How would I patch those
> in?
> /#!/JoePea
>
>
> On Tue, Oct 24, 2017 at 10:07 AM, Michał Wadas  wrote:
>> AFAIR DOM classes are not extensible by any means.
>>
>>
>>
>> On 24 Oct 2017 6:51 pm, "/#!/JoePea"  wrote:
>>>
>>> Is it possible to monkey-patch an intermediate constructor of a built-in
>>> subclass?
>>>
>>> For example, suppose I want all `Element` instances in a web app to have
>>> new instance properties, is there a way to monkey-patch the Element
>>> constructor so that when I make a custom element by extending a subclass of
>>> `Element` that the new logic will fire?
>>>
>>> For example:
>>>
>>> ```js
>>> // monkey-patch the Element constructor somehow so that it logs "patched
>>> in Element".
>>>
>>> // then
>>> class FooBar extends HTMLElement {}
>>> customElement.define('foo-bar', FooBar)
>>> new FooBar // "patched in Element"
>>> ```
>>>
>>> I tried
>>>
>>> ```js
>>> const OldElement = window.Element
>>>
>>> window.Element = function Element() {
>>>   const _this = new OldElement
>>>   console.log("patched in Element")
>>>   return _this
>>> }
>>>
>>> window.Element.prototype = OldElement.prototype
>>> window.Element.prototype.constructor = window.Element
>>>
>>> class FooBar extends HTMLElement {}
>>> customElements.define('f-b', FooBar)
>>> new FooBar // does not log "patched in Element"
>>> ```
>>>
>>> But when I make a new custom element, constructing it seems to use the old
>>> Element constructor, as if a non-global reference to the original
>>> constructor is kept inside a module so that modifying the global wouldn't
>>> have any effect.
>>>
>>> Is there a way to monkey patch a constructor in the middle of a built-in
>>> prototype chain or to otherwise inject construction logic to base classes of
>>> existing class hierarchies?
>>>
>>>
>>> /#!/JoePea
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Monkey patching constructors in builtin class hierarchies?

[/#!/JoePea]

> This feels like a problem similar to 
> https://esdiscuss.org/topic/block-scoped-prototype-extensions

@Boris, even if it were scoped, how do we monkey patch a
*constructor*? By the way, for some reason your link to
`https://esdiscuss.org/topic/block-scoped-prototype-extensions` posted
as `https://esdiscuss.org/topic/block` which is 404. If you can edit
it it would help others not to stumble on a broken link.

> if that would be possible, then everyone could just monkey patch Object, 
> right?

But everyone can monkey patch the entire class already, aside from the
constructor, by modifying the prototype. Obviously if someone returns
something new from the constructor they might break everything, but it
will be completely obvious and people then won't do that. The same
applies with methods and properties, it is super easy to break entire
applications monkey patching methods.

---

So suppose I want to "polyfill" a concept. For example, I want all
elements to have a new "foo" accessor after they've been constructed.
Or for example, suppose `HTMLElement.prototype.style` and
`SVGElement.prototype.style` didn't exist yet. How would I patch those
in?
/#!/JoePea


On Tue, Oct 24, 2017 at 10:07 AM, Michał Wadas  wrote:
> AFAIR DOM classes are not extensible by any means.
>
>
>
> On 24 Oct 2017 6:51 pm, "/#!/JoePea"  wrote:
>>
>> Is it possible to monkey-patch an intermediate constructor of a built-in
>> subclass?
>>
>> For example, suppose I want all `Element` instances in a web app to have
>> new instance properties, is there a way to monkey-patch the Element
>> constructor so that when I make a custom element by extending a subclass of
>> `Element` that the new logic will fire?
>>
>> For example:
>>
>> ```js
>> // monkey-patch the Element constructor somehow so that it logs "patched
>> in Element".
>>
>> // then
>> class FooBar extends HTMLElement {}
>> customElement.define('foo-bar', FooBar)
>> new FooBar // "patched in Element"
>> ```
>>
>> I tried
>>
>> ```js
>> const OldElement = window.Element
>>
>> window.Element = function Element() {
>>   const _this = new OldElement
>>   console.log("patched in Element")
>>   return _this
>> }
>>
>> window.Element.prototype = OldElement.prototype
>> window.Element.prototype.constructor = window.Element
>>
>> class FooBar extends HTMLElement {}
>> customElements.define('f-b', FooBar)
>> new FooBar // does not log "patched in Element"
>> ```
>>
>> But when I make a new custom element, constructing it seems to use the old
>> Element constructor, as if a non-global reference to the original
>> constructor is kept inside a module so that modifying the global wouldn't
>> have any effect.
>>
>> Is there a way to monkey patch a constructor in the middle of a built-in
>> prototype chain or to otherwise inject construction logic to base classes of
>> existing class hierarchies?
>>
>>
>> /#!/JoePea
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Shorter syntax for arrow function assignment

[Brian Blakely]

>Also, you cannot implicitly omit the "const"

Paving a cowpath, const has won named function assignment.

On Tue, Oct 24, 2017 at 1:16 PM, dante federici 
wrote:

> My major concern is this can be confusing with the "this" binding.
> The object wrapping being the only difference between:
> ```
> // Existing:
> const x = {
>   myFn() { }
> };
>
> // Proposed, with different meaning:
> const myFn() { } // Why would "this" bind to myFn?
> ```
> Omitting the arrow is a major -1 for me -- the whole point of "=>" is that
> it does not provide a "this" to the scope of the function body.
>
> Also, you cannot implicitly omit the "const", as these are all valid:
> ```
> export var symbol = ...
> export let symbol = ...
> export const symbol = ...
> ```
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Shorter syntax for arrow function assignment

[dante federici]

My major concern is this can be confusing with the "this" binding.
The object wrapping being the only difference between:
```
// Existing:
const x = {
  myFn() { }
};

// Proposed, with different meaning:
const myFn() { } // Why would "this" bind to myFn?
```
Omitting the arrow is a major -1 for me -- the whole point of "=>" is that
it does not provide a "this" to the scope of the function body.

Also, you cannot implicitly omit the "const", as these are all valid:
```
export var symbol = ...
export let symbol = ...
export const symbol = ...
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Shorter syntax for arrow function assignment

[Brian Blakely]

ICYMI: my stance is that ES5- functions are already outmoded - and are
rapidly becoming the lesser-used option - so it would be a waste of a
syntax win.

On Tue, Oct 24, 2017 at 1:11 PM, Michał Wadas  wrote:

> +1 for omitting function keyword between export and function name.
>
> Declaring arrow functions without arrow in syntax - nope, nope, nope.
>
> On 24 Oct 2017 7:01 pm, "Andrea Giammarchi" 
> wrote:
>
>> to me this `export foo() {}` makes sense only as shortcut for `export
>> function foo() {}` and not as arrow, because arrow missing context and
>> arguments will mislead everyone exporting a named function.
>>
>> -1
>>
>> On Tue, Oct 24, 2017 at 1:59 PM, Brian Blakely 
>> wrote:
>>
>>> As arrow function const assignments become the norm and non-arrows the
>>> exception, allowing syntactical cruft to fall away makes sense to me.  It
>>> might be premature based on overall 2015 adoption, but I don't see this
>>> trend reversing.
>>>
>>> On Tue, Oct 24, 2017 at 12:54 PM, /#!/JoePea  wrote:
>>>
 It can be confusing because it is too similar to non-arrow functions.
 The arrow syntax is clear in meaning.

 */#!/*JoePea

 On Tue, Oct 24, 2017 at 9:51 AM, Brian Blakely <
 anewpage.me...@gmail.com> wrote:

> This syntax is shorter, easier to write, and arguably easier to read.
> What else does it need to offer?
>
> On Tue, Oct 24, 2017 at 12:48 PM, kai zhu  wrote:
>
>> -1
>> this fails styleguide sanity-check.
>>
>> we currently have 3 common styles of declaring functions:
>> 1. foo = function () {...}
>> 2. function foo () {...}
>> 3. foo = () => {...}
>>
>> does this extra 4th style offer anything new to justify making the
>> javascript language even less consistent than it already is?  i say
>> no.
>>
>>
>> On 10/25/17, Brian Blakely  wrote:
>> > A prevalent pattern has emerged:
>> >
>> > `export const foo = ()=> { };`
>> >
>> > Taking a cue from short method syntax, this comes to mind as a
>> possible
>> > improvement:
>> >
>> > `export const foo() { };`
>> >
>> > Even better if we assume const:
>> >
>> > `export foo() { };`
>> >
>> > That is delicious.  Thoughts?
>> >
>>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>

>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Monkey patching constructors in builtin class hierarchies?

[Oriol _]

The problem is that DOM defines the [`Element` 
interface](https://dom.spec.whatwg.org/#element) without a [\[Constructor\] 
extended attribute](https://heycam.github.io/webidl/#Constructor).


This means that `Element` can't be directly constructed. However, you can still 
use something like

```js
class FooBar extends Element {
  constructor() {
console.log("patched in Element");
let el = document.createElement('foo-bar');
return Object.setPrototypeOf(el, FooBar.prototype);
  }
}
```


-Oriol

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Shorter syntax for arrow function assignment

[T.J. Crowder]

Agree with Andrea on this one. Method syntax (in an object initializer, in
a `class`) creates a method (a non-arrow function with a [[HomeObject]]
slot), not an arrow function. This looks just like method syntax. The
absence of the arrow is too misleading.

I could see it as a shortcut for `export function foo() { }`, but not for
`export const foo = () => { };`.

-- T.J. Crowder

On Tue, Oct 24, 2017 at 6:01 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> to me this `export foo() {}` makes sense only as shortcut for `export
> function foo() {}` and not as arrow, because arrow missing context and
> arguments will mislead everyone exporting a named function.
>
> -1
>
> On Tue, Oct 24, 2017 at 1:59 PM, Brian Blakely 
> wrote:
>
>> As arrow function const assignments become the norm and non-arrows the
>> exception, allowing syntactical cruft to fall away makes sense to me.  It
>> might be premature based on overall 2015 adoption, but I don't see this
>> trend reversing.
>>
>> On Tue, Oct 24, 2017 at 12:54 PM, /#!/JoePea  wrote:
>>
>>> It can be confusing because it is too similar to non-arrow functions.
>>> The arrow syntax is clear in meaning.
>>>
>>> */#!/*JoePea
>>>
>>> On Tue, Oct 24, 2017 at 9:51 AM, Brian Blakely >> > wrote:
>>>
 This syntax is shorter, easier to write, and arguably easier to read.
 What else does it need to offer?

 On Tue, Oct 24, 2017 at 12:48 PM, kai zhu  wrote:

> -1
> this fails styleguide sanity-check.
>
> we currently have 3 common styles of declaring functions:
> 1. foo = function () {...}
> 2. function foo () {...}
> 3. foo = () => {...}
>
> does this extra 4th style offer anything new to justify making the
> javascript language even less consistent than it already is?  i say
> no.
>
>
> On 10/25/17, Brian Blakely  wrote:
> > A prevalent pattern has emerged:
> >
> > `export const foo = ()=> { };`
> >
> > Taking a cue from short method syntax, this comes to mind as a
> possible
> > improvement:
> >
> > `export const foo() { };`
> >
> > Even better if we assume const:
> >
> > `export foo() { };`
> >
> > That is delicious.  Thoughts?
> >
>


 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss


>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Shorter syntax for arrow function assignment

[Brian Blakely]

I certainly understand the "misleading" perspective, but also consider ES5-
function syntax to be deteriorating such that this shorthand would be
wasted on it.

On Tue, Oct 24, 2017 at 1:01 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> to me this `export foo() {}` makes sense only as shortcut for `export
> function foo() {}` and not as arrow, because arrow missing context and
> arguments will mislead everyone exporting a named function.
>
> -1
>
> On Tue, Oct 24, 2017 at 1:59 PM, Brian Blakely 
> wrote:
>
>> As arrow function const assignments become the norm and non-arrows the
>> exception, allowing syntactical cruft to fall away makes sense to me.  It
>> might be premature based on overall 2015 adoption, but I don't see this
>> trend reversing.
>>
>> On Tue, Oct 24, 2017 at 12:54 PM, /#!/JoePea  wrote:
>>
>>> It can be confusing because it is too similar to non-arrow functions.
>>> The arrow syntax is clear in meaning.
>>>
>>> */#!/*JoePea
>>>
>>> On Tue, Oct 24, 2017 at 9:51 AM, Brian Blakely >> > wrote:
>>>
 This syntax is shorter, easier to write, and arguably easier to read.
 What else does it need to offer?

 On Tue, Oct 24, 2017 at 12:48 PM, kai zhu  wrote:

> -1
> this fails styleguide sanity-check.
>
> we currently have 3 common styles of declaring functions:
> 1. foo = function () {...}
> 2. function foo () {...}
> 3. foo = () => {...}
>
> does this extra 4th style offer anything new to justify making the
> javascript language even less consistent than it already is?  i say
> no.
>
>
> On 10/25/17, Brian Blakely  wrote:
> > A prevalent pattern has emerged:
> >
> > `export const foo = ()=> { };`
> >
> > Taking a cue from short method syntax, this comes to mind as a
> possible
> > improvement:
> >
> > `export const foo() { };`
> >
> > Even better if we assume const:
> >
> > `export foo() { };`
> >
> > That is delicious.  Thoughts?
> >
>


 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss


>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Shorter syntax for arrow function assignment

[Michał Wadas]

+1 for omitting function keyword between export and function name.

Declaring arrow functions without arrow in syntax - nope, nope, nope.

On 24 Oct 2017 7:01 pm, "Andrea Giammarchi" 
wrote:

> to me this `export foo() {}` makes sense only as shortcut for `export
> function foo() {}` and not as arrow, because arrow missing context and
> arguments will mislead everyone exporting a named function.
>
> -1
>
> On Tue, Oct 24, 2017 at 1:59 PM, Brian Blakely 
> wrote:
>
>> As arrow function const assignments become the norm and non-arrows the
>> exception, allowing syntactical cruft to fall away makes sense to me.  It
>> might be premature based on overall 2015 adoption, but I don't see this
>> trend reversing.
>>
>> On Tue, Oct 24, 2017 at 12:54 PM, /#!/JoePea  wrote:
>>
>>> It can be confusing because it is too similar to non-arrow functions.
>>> The arrow syntax is clear in meaning.
>>>
>>> */#!/*JoePea
>>>
>>> On Tue, Oct 24, 2017 at 9:51 AM, Brian Blakely >> > wrote:
>>>
 This syntax is shorter, easier to write, and arguably easier to read.
 What else does it need to offer?

 On Tue, Oct 24, 2017 at 12:48 PM, kai zhu  wrote:

> -1
> this fails styleguide sanity-check.
>
> we currently have 3 common styles of declaring functions:
> 1. foo = function () {...}
> 2. function foo () {...}
> 3. foo = () => {...}
>
> does this extra 4th style offer anything new to justify making the
> javascript language even less consistent than it already is?  i say
> no.
>
>
> On 10/25/17, Brian Blakely  wrote:
> > A prevalent pattern has emerged:
> >
> > `export const foo = ()=> { };`
> >
> > Taking a cue from short method syntax, this comes to mind as a
> possible
> > improvement:
> >
> > `export const foo() { };`
> >
> > Even better if we assume const:
> >
> > `export foo() { };`
> >
> > That is delicious.  Thoughts?
> >
>


 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss


>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Monkey patching constructors in builtin class hierarchies?

[Michał Wadas]

AFAIR DOM classes are not extensible by any means.



On 24 Oct 2017 6:51 pm, "/#!/JoePea"  wrote:

> Is it possible to monkey-patch an intermediate constructor of a built-in
> subclass?
>
> For example, suppose I want all `Element` instances in a web app to have
> new instance properties, is there a way to monkey-patch the Element
> constructor so that when I make a custom element by extending a subclass of
> `Element` that the new logic will fire?
>
> For example:
>
> ```js
> // monkey-patch the Element constructor somehow so that it logs "patched
> in Element".
>
> // then
> class FooBar extends HTMLElement {}
> customElement.define('foo-bar', FooBar)
> new FooBar // "patched in Element"
> ```
>
> I tried
>
> ```js
> const OldElement = window.Element
>
> window.Element = function Element() {
>   const _this = new OldElement
>   console.log("patched in Element")
>   return _this
> }
>
> window.Element.prototype = OldElement.prototype
> window.Element.prototype.constructor = window.Element
>
> class FooBar extends HTMLElement {}
> customElements.define('f-b', FooBar)
> new FooBar // does not log "patched in Element"
> ```
>
> But when I make a new custom element, constructing it seems to use the old
> Element constructor, as if a non-global reference to the original
> constructor is kept inside a module so that modifying the global wouldn't
> have any effect.
>
> Is there a way to monkey patch a constructor in the middle of a built-in
> prototype chain or to otherwise inject construction logic to base classes
> of existing class hierarchies?
>
>
> */#!/*JoePea
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Monkey patching constructors in builtin class hierarchies?

[Andrea Giammarchi]

if that would be possible, then everyone could just monkey patch `Object`,
right?

I'm not sure I'd be up for it

On Tue, Oct 24, 2017 at 1:56 PM, Boris Cherny 
wrote:

> This feels like a problem similar to https://esdiscuss.org/
> topic/block-scoped-prototype-extensions
>
> On Oct 24, 2017, at 9:50 AM, /#!/JoePea  wrote:
>
> Is it possible to monkey-patch an intermediate constructor of a built-in
> subclass?
>
> For example, suppose I want all `Element` instances in a web app to have
> new instance properties, is there a way to monkey-patch the Element
> constructor so that when I make a custom element by extending a subclass of
> `Element` that the new logic will fire?
>
> For example:
>
> ```js
> // monkey-patch the Element constructor somehow so that it logs "patched
> in Element".
>
> // then
> class FooBar extends HTMLElement {}
> customElement.define('foo-bar', FooBar)
> new FooBar // "patched in Element"
> ```
>
> I tried
>
> ```js
> const OldElement = window.Element
>
> window.Element = function Element() {
>   const _this = new OldElement
>   console.log("patched in Element")
>   return _this
> }
>
> window.Element.prototype = OldElement.prototype
> window.Element.prototype.constructor = window.Element
>
> class FooBar extends HTMLElement {}
> customElements.define('f-b', FooBar)
> new FooBar // does not log "patched in Element"
> ```
>
> But when I make a new custom element, constructing it seems to use the old
> Element constructor, as if a non-global reference to the original
> constructor is kept inside a module so that modifying the global wouldn't
> have any effect.
>
> Is there a way to monkey patch a constructor in the middle of a built-in
> prototype chain or to otherwise inject construction logic to base classes
> of existing class hierarchies?
>
>
> */#!/*JoePea
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Shorter syntax for arrow function assignment

[Andrea Giammarchi]

to me this `export foo() {}` makes sense only as shortcut for `export
function foo() {}` and not as arrow, because arrow missing context and
arguments will mislead everyone exporting a named function.

-1

On Tue, Oct 24, 2017 at 1:59 PM, Brian Blakely 
wrote:

> As arrow function const assignments become the norm and non-arrows the
> exception, allowing syntactical cruft to fall away makes sense to me.  It
> might be premature based on overall 2015 adoption, but I don't see this
> trend reversing.
>
> On Tue, Oct 24, 2017 at 12:54 PM, /#!/JoePea  wrote:
>
>> It can be confusing because it is too similar to non-arrow functions. The
>> arrow syntax is clear in meaning.
>>
>> */#!/*JoePea
>>
>> On Tue, Oct 24, 2017 at 9:51 AM, Brian Blakely 
>> wrote:
>>
>>> This syntax is shorter, easier to write, and arguably easier to read.
>>> What else does it need to offer?
>>>
>>> On Tue, Oct 24, 2017 at 12:48 PM, kai zhu  wrote:
>>>
 -1
 this fails styleguide sanity-check.

 we currently have 3 common styles of declaring functions:
 1. foo = function () {...}
 2. function foo () {...}
 3. foo = () => {...}

 does this extra 4th style offer anything new to justify making the
 javascript language even less consistent than it already is?  i say
 no.


 On 10/25/17, Brian Blakely  wrote:
 > A prevalent pattern has emerged:
 >
 > `export const foo = ()=> { };`
 >
 > Taking a cue from short method syntax, this comes to mind as a
 possible
 > improvement:
 >
 > `export const foo() { };`
 >
 > Even better if we assume const:
 >
 > `export foo() { };`
 >
 > That is delicious.  Thoughts?
 >

>>>
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Shorter syntax for arrow function assignment

[Brian Blakely]

As arrow function const assignments become the norm and non-arrows the
exception, allowing syntactical cruft to fall away makes sense to me.  It
might be premature based on overall 2015 adoption, but I don't see this
trend reversing.

On Tue, Oct 24, 2017 at 12:54 PM, /#!/JoePea  wrote:

> It can be confusing because it is too similar to non-arrow functions. The
> arrow syntax is clear in meaning.
>
> */#!/*JoePea
>
> On Tue, Oct 24, 2017 at 9:51 AM, Brian Blakely 
> wrote:
>
>> This syntax is shorter, easier to write, and arguably easier to read.
>> What else does it need to offer?
>>
>> On Tue, Oct 24, 2017 at 12:48 PM, kai zhu  wrote:
>>
>>> -1
>>> this fails styleguide sanity-check.
>>>
>>> we currently have 3 common styles of declaring functions:
>>> 1. foo = function () {...}
>>> 2. function foo () {...}
>>> 3. foo = () => {...}
>>>
>>> does this extra 4th style offer anything new to justify making the
>>> javascript language even less consistent than it already is?  i say
>>> no.
>>>
>>>
>>> On 10/25/17, Brian Blakely  wrote:
>>> > A prevalent pattern has emerged:
>>> >
>>> > `export const foo = ()=> { };`
>>> >
>>> > Taking a cue from short method syntax, this comes to mind as a possible
>>> > improvement:
>>> >
>>> > `export const foo() { };`
>>> >
>>> > Even better if we assume const:
>>> >
>>> > `export foo() { };`
>>> >
>>> > That is delicious.  Thoughts?
>>> >
>>>
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Monkey patching constructors in builtin class hierarchies?

[Boris Cherny]

This feels like a problem similar to 
https://esdiscuss.org/topic/block-scoped-prototype-extensions

> On Oct 24, 2017, at 9:50 AM, /#!/JoePea  wrote:
> 
> Is it possible to monkey-patch an intermediate constructor of a built-in 
> subclass?
> 
> For example, suppose I want all `Element` instances in a web app to have new 
> instance properties, is there a way to monkey-patch the Element constructor 
> so that when I make a custom element by extending a subclass of `Element` 
> that the new logic will fire?
> 
> For example:
> 
> ```js
> // monkey-patch the Element constructor somehow so that it logs "patched in 
> Element".
> 
> // then
> class FooBar extends HTMLElement {}
> customElement.define('foo-bar', FooBar)
> new FooBar // "patched in Element"
> ```
> 
> I tried
> 
> ```js
> const OldElement = window.Element
> 
> window.Element = function Element() {
>   const _this = new OldElement
>   console.log("patched in Element")
>   return _this
> }
> 
> window.Element.prototype = OldElement.prototype
> window.Element.prototype.constructor = window.Element
> 
> class FooBar extends HTMLElement {}
> customElements.define('f-b', FooBar)
> new FooBar // does not log "patched in Element"
> ```
> 
> But when I make a new custom element, constructing it seems to use the old 
> Element constructor, as if a non-global reference to the original constructor 
> is kept inside a module so that modifying the global wouldn't have any effect.
> 
> Is there a way to monkey patch a constructor in the middle of a built-in 
> prototype chain or to otherwise inject construction logic to base classes of 
> existing class hierarchies?
> 
> 
> /#!/JoePea
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Shorter syntax for arrow function assignment

[/#!/JoePea]

It can be confusing because it is too similar to non-arrow functions. The
arrow syntax is clear in meaning.

*/#!/*JoePea

On Tue, Oct 24, 2017 at 9:51 AM, Brian Blakely 
wrote:

> This syntax is shorter, easier to write, and arguably easier to read.
> What else does it need to offer?
>
> On Tue, Oct 24, 2017 at 12:48 PM, kai zhu  wrote:
>
>> -1
>> this fails styleguide sanity-check.
>>
>> we currently have 3 common styles of declaring functions:
>> 1. foo = function () {...}
>> 2. function foo () {...}
>> 3. foo = () => {...}
>>
>> does this extra 4th style offer anything new to justify making the
>> javascript language even less consistent than it already is?  i say
>> no.
>>
>>
>> On 10/25/17, Brian Blakely  wrote:
>> > A prevalent pattern has emerged:
>> >
>> > `export const foo = ()=> { };`
>> >
>> > Taking a cue from short method syntax, this comes to mind as a possible
>> > improvement:
>> >
>> > `export const foo() { };`
>> >
>> > Even better if we assume const:
>> >
>> > `export foo() { };`
>> >
>> > That is delicious.  Thoughts?
>> >
>>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Shorter syntax for arrow function assignment

[Peter Jaszkowiak]

It needs to offer more than two characters, and no confusing confliction
with shorthand method syntax.

On Oct 24, 2017 10:48, "kai zhu"  wrote:

> -1
> this fails styleguide sanity-check.
>
> we currently have 3 common styles of declaring functions:
> 1. foo = function () {...}
> 2. function foo () {...}
> 3. foo = () => {...}
>
> does this extra 4th style offer anything new to justify making the
> javascript language even less consistent than it already is?  i say
> no.
>
>
> On 10/25/17, Brian Blakely  wrote:
> > A prevalent pattern has emerged:
> >
> > `export const foo = ()=> { };`
> >
> > Taking a cue from short method syntax, this comes to mind as a possible
> > improvement:
> >
> > `export const foo() { };`
> >
> > Even better if we assume const:
> >
> > `export foo() { };`
> >
> > That is delicious.  Thoughts?
> >
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Shorter syntax for arrow function assignment

[Brian Blakely]

This syntax is shorter, easier to write, and arguably easier to read.  What
else does it need to offer?

On Tue, Oct 24, 2017 at 12:48 PM, kai zhu  wrote:

> -1
> this fails styleguide sanity-check.
>
> we currently have 3 common styles of declaring functions:
> 1. foo = function () {...}
> 2. function foo () {...}
> 3. foo = () => {...}
>
> does this extra 4th style offer anything new to justify making the
> javascript language even less consistent than it already is?  i say
> no.
>
>
> On 10/25/17, Brian Blakely  wrote:
> > A prevalent pattern has emerged:
> >
> > `export const foo = ()=> { };`
> >
> > Taking a cue from short method syntax, this comes to mind as a possible
> > improvement:
> >
> > `export const foo() { };`
> >
> > Even better if we assume const:
> >
> > `export foo() { };`
> >
> > That is delicious.  Thoughts?
> >
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Monkey patching constructors in builtin class hierarchies?

[/#!/JoePea]

Is it possible to monkey-patch an intermediate constructor of a built-in
subclass?

For example, suppose I want all `Element` instances in a web app to have
new instance properties, is there a way to monkey-patch the Element
constructor so that when I make a custom element by extending a subclass of
`Element` that the new logic will fire?

For example:

```js
// monkey-patch the Element constructor somehow so that it logs "patched in
Element".

// then
class FooBar extends HTMLElement {}
customElement.define('foo-bar', FooBar)
new FooBar // "patched in Element"
```

I tried

```js
const OldElement = window.Element

window.Element = function Element() {
  const _this = new OldElement
  console.log("patched in Element")
  return _this
}

window.Element.prototype = OldElement.prototype
window.Element.prototype.constructor = window.Element

class FooBar extends HTMLElement {}
customElements.define('f-b', FooBar)
new FooBar // does not log "patched in Element"
```

But when I make a new custom element, constructing it seems to use the old
Element constructor, as if a non-global reference to the original
constructor is kept inside a module so that modifying the global wouldn't
have any effect.

Is there a way to monkey patch a constructor in the middle of a built-in
prototype chain or to otherwise inject construction logic to base classes
of existing class hierarchies?


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

Re: Shorter syntax for arrow function assignment

[kai zhu]

-1
this fails styleguide sanity-check.

we currently have 3 common styles of declaring functions:
1. foo = function () {...}
2. function foo () {...}
3. foo = () => {...}

does this extra 4th style offer anything new to justify making the
javascript language even less consistent than it already is?  i say
no.


On 10/25/17, Brian Blakely  wrote:
> A prevalent pattern has emerged:
>
> `export const foo = ()=> { };`
>
> Taking a cue from short method syntax, this comes to mind as a possible
> improvement:
>
> `export const foo() { };`
>
> Even better if we assume const:
>
> `export foo() { };`
>
> That is delicious.  Thoughts?
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Shorter syntax for arrow function assignment

[Brian Blakely]

A prevalent pattern has emerged:

`export const foo = ()=> { };`

Taking a cue from short method syntax, this comes to mind as a possible
improvement:

`export const foo() { };`

Even better if we assume const:

`export foo() { };`

That is delicious.  Thoughts?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss