Re: A new proposal for syntax-checking and sandbox: ECMAScript Parser proposal

[Isiah Meadows]

Nit: Acorn's *output* is based on Esprima. Its code is *not* and
hasn't been for a few years now. It started a fork of Esprima, but it
wasn't long before it was rewritten the first time.

-

Isiah Meadows
cont...@isiahmeadows.com
www.isiahmeadows.com

On Mon, Sep 16, 2019 at 1:58 AM kai zhu  wrote:
>
> adding datapoint on application in code-coverage.
>
> a builtin parser-api would be ideal (and appreciate the insight on 
> implementation difficulties).
> lacking that, the next best alternative i've found is acorn (based on 
> esprima),
> available as a single, embedabble file runnable in browser:
>
> ```shell
> curl https://registry.npmjs.org/acorn/-/acorn-6.3.0.tgz | tar -O -xz 
> package/dist/acorn.js > acorn.rollup.js
> ls -l acorn.rollup.js
> -rwxr-xr-x 1 root root 191715 Sep 15 16:49 acorn.rollup.js
> ```
>
> i recently added es9 syntax-support to in-browser-variant of istanbul by 
> replacing its aging esprima-parser with acorn [1].
> ideally, i hope a standardized ast will be available someday, and get rid of 
> acorn/babel/shift altogether (or maybe acorn can become that standard?).
> even better, is if [cross-compatible] instrumentation becomes a common 
> bultin-feature in engines, and get rid of istanbul.
>
> chrome/puppeteer's instrumentation-api is not yet ideal for my use-case 
> because it currently lack code-coverage-info on branches (which 
> istanbul-instrumentation provides).
>
> [1] istanbul-lite - embeddable, es9 browser-variant of istanbul code-coverage
> https://kaizhu256.github.io/node-istanbul-lite/build..beta..travis-ci.org/app/
>
>
>
> On Sun, Sep 15, 2019 at 9:08 AM David Teller  wrote:
>>
>> In theory, it should be possible to have both modes, if the parser is
>> designed for it. Unfortunately, that's not the case at the moment.
>>
>> Mozilla has recently started working on a new parser which could be used
>> both by VMs and by JS/wasm devs. It might help towards this issue, but
>> it's still early days.
>>
>> Cheers,
>>  David
>>
>> On 15/09/2019 13:09, Jack Works wrote:
>> > Happy to see standard ast in binary ast proposal.
>> >
>> > For compiler, it can have a "slow" mode when parsing with this parser
>> > API and still use fast code generation in other cases. But unfortunately
>> > it seems there are much more work than I think to provide such an API.
>> >
>> ___
>> 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: A new proposal for syntax-checking and sandbox: ECMAScript Parser proposal

[kai zhu]

adding datapoint on application in code-coverage.

a builtin parser-api would be ideal (and appreciate the insight on
implementation difficulties).
lacking that, the next best alternative i've found is acorn (based on
esprima),
available as a single, embedabble file runnable in browser:

```shell
curl https://registry.npmjs.org/acorn/-/acorn-6.3.0.tgz | tar -O -xz
package/dist/acorn.js > acorn.rollup.js
ls -l acorn.rollup.js
-rwxr-xr-x 1 root root 191715 Sep 15 16:49 acorn.rollup.js
```

i recently added es9 syntax-support to in-browser-variant of istanbul by
replacing its aging esprima-parser with acorn [1].
ideally, i hope a standardized ast will be available someday, and get rid
of acorn/babel/shift altogether (or maybe acorn can become that standard?).
even better, is if [cross-compatible] instrumentation becomes a common
bultin-feature in engines, and get rid of istanbul.

chrome/puppeteer's instrumentation-api is not yet ideal for my use-case
because it currently lack code-coverage-info on branches (which
istanbul-instrumentation provides).

[1] istanbul-lite - embeddable, es9 browser-variant of istanbul
code-coverage
https://kaizhu256.github.io/node-istanbul-lite/build..beta..travis-ci.org/app/




On Sun, Sep 15, 2019 at 9:08 AM David Teller  wrote:

> In theory, it should be possible to have both modes, if the parser is
> designed for it. Unfortunately, that's not the case at the moment.
>
> Mozilla has recently started working on a new parser which could be used
> both by VMs and by JS/wasm devs. It might help towards this issue, but
> it's still early days.
>
> Cheers,
>  David
>
> On 15/09/2019 13:09, Jack Works wrote:
> > Happy to see standard ast in binary ast proposal.
> >
> > For compiler, it can have a "slow" mode when parsing with this parser
> > API and still use fast code generation in other cases. But unfortunately
> > it seems there are much more work than I think to provide such an API.
> >
> ___
> 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: A new proposal for syntax-checking and sandbox: ECMAScript Parser proposal

[David Teller]

In theory, it should be possible to have both modes, if the parser is
designed for it. Unfortunately, that's not the case at the moment.

Mozilla has recently started working on a new parser which could be used
both by VMs and by JS/wasm devs. It might help towards this issue, but
it's still early days.

Cheers,
 David

On 15/09/2019 13:09, Jack Works wrote:
> Happy to see standard ast in binary ast proposal.
> 
> For compiler, it can have a "slow" mode when parsing with this parser
> API and still use fast code generation in other cases. But unfortunately
> it seems there are much more work than I think to provide such an API.
> 
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: A new proposal for syntax-checking and sandbox: ECMAScript Parser proposal

[Jack Works]

Happy to see standard ast in binary ast proposal.

For compiler, it can have a "slow" mode when parsing with this parser API
and still use fast code generation in other cases. But unfortunately it
seems there are much more work than I think to provide such an API.

David Teller  于 2019年9月15日周日 下午7:02写道：

> Before you can have a standard parser, you need a standard AST. There is
> no such thing as the moment, so the v8 parser, the SpiderMonkey parser
> and the JSCore parser, etc. all use distinct internal ASTs, each of
> which changes every so often, either because the language changes or
> because the VM needs to attach different information to help with
> compilation.
>
> That's the main reason for which there hasn't been a standard
> user-accessible ECMAScript parser in ECMAScript.
>
> As Binary AST relies upon having a standard AST, standandardizing the
> AST is part of the Binary AST proposal. You may find the latest version
> of this AST online
> https://github.com/binast/binjs-ref/blob/master/spec/es6.webidl
>
> Cheers,
>  David
>
> On 14/09/2019 10:10, Jack Works wrote:
> > This proposal is not a part of the binary AST proposal. Because that
> > proposal wants a binary representation and will not generate AST
> > directly from the ecmascript spec.
> > Because run those parsers in browser is pretty slow. Since the JS engine
> > can already parse the JavaScript code, just expose those interfaces will
> > make things easier.
> >
> >
> > Out of curiosity, what is the expected benefit wrt Esprima, Babel or
> > Shift? In particular since there is no standard AST for ECMAScript
> > yet [1]?
> >
> > Cheers,
> >  David
> >
> > [1] Ok, that's a subset of
> https://github.com/tc39/proposal-binary-ast,
> > which is in the pipes.
> >
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: A new proposal for syntax-checking and sandbox: ECMAScript Parser proposal

[David Teller]

Before you can have a standard parser, you need a standard AST. There is
no such thing as the moment, so the v8 parser, the SpiderMonkey parser
and the JSCore parser, etc. all use distinct internal ASTs, each of
which changes every so often, either because the language changes or
because the VM needs to attach different information to help with
compilation.

That's the main reason for which there hasn't been a standard
user-accessible ECMAScript parser in ECMAScript.

As Binary AST relies upon having a standard AST, standandardizing the
AST is part of the Binary AST proposal. You may find the latest version
of this AST online
https://github.com/binast/binjs-ref/blob/master/spec/es6.webidl

Cheers,
 David

On 14/09/2019 10:10, Jack Works wrote:
> This proposal is not a part of the binary AST proposal. Because that
> proposal wants a binary representation and will not generate AST
> directly from the ecmascript spec.
> Because run those parsers in browser is pretty slow. Since the JS engine
> can already parse the JavaScript code, just expose those interfaces will
> make things easier.
> 
> 
> Out of curiosity, what is the expected benefit wrt Esprima, Babel or
> Shift? In particular since there is no standard AST for ECMAScript
> yet [1]?
> 
> Cheers,
>  David
> 
> [1] Ok, that's a subset of https://github.com/tc39/proposal-binary-ast,
> which is in the pipes.
> 
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: A new proposal for syntax-checking and sandbox: ECMAScript Parser proposal

[Isiah Meadows]

I do want to note a couple things here, as someone familiar with the
implementation aspect of JS and programming languages in general:

1. The HTML and CSS parsers (for inline style sheets) have to build a
full DOM trees for each anyways just to conform to spec, so they can't
just, say, parse `.foo { display: block; color: red; }` as `.foo {
display: block; } .foo { color: red }` with a cached selector (which
*would* be easier to process later on). In this case, they're
basically just exposing the same parsers they'd have to use in
practice anyways, so it's literally trivial for them to add.
2. No JS engine parses nodes the way the spec processes them, just in
a way it's unobservable mod timings. They internally parse `1` and
`1.0` as different types, and they will do things like constant
propagation - `3 * 5` gets parsed as `15` usually, and `"a" + "b"`
will usually get read as `"ab"` by some engines. Furthermore, browser
engines lazily parse functions where they can, only validating them
for early errors and storing the source code to reparse them on first
call, because it helps them start up faster with less memory. And of
course, `typeof value === "string"` is often not simply compiled to
`%IsString(value)` but literally parsed as such if `value` is defined
in that scope. And finally, engines typically merge the steps of AST
generation and scope detection, not only to detect `let`/`const`
errors but also to speed up bytecode generation.

So although it sounds like JS engines could reuse their logic, they
really couldn't. This is further evidenced by SpiderMonkey's parser
API (the predecessor to the ESTree spec) not sharing the same
implementation as the core language parser. There's two vastly
different concerns between generating an AST for tooling and
generating an AST to execute. In the former, you want as much info as
possible readily available. In the latter, you just want to have the
bare minimum to compile to bytecode with relevant source locations for
stack traces, and anything else is literally just unnecessary
overhead.

-

Isiah Meadows
cont...@isiahmeadows.com
www.isiahmeadows.com

On Sat, Sep 14, 2019 at 9:41 AM Gareth Heyes
 wrote:
>
> I had a few goes with making a JS sandbox. I also created a safe DOM 
> environment that allowed safe manipulation of innerHTML etc
>
> JS sandbox with regular expressions
> http://www.businessinfo.co.uk/labs/jsreg/jsreg.html
>
> JS sandbox and safe DOM environment
> http://businessinfo.co.uk/labs/MentalJS/MentalJS.html
>
> It would be great to have a parser in JS!
>
> On 14 Sep 2019, at 06:46, Jack Works  wrote:
>
> Just like DOMParser in HTML and Houdini's parser API in CSS, a built-in 
> parser for ECMAScript itself is quite useful in many ways.
>
> Check out https://github.com/Jack-Works/proposal-ecmascript-parser for 
> details (and also, finding champions!)
>
>
> ___
> 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: A new proposal for syntax-checking and sandbox: ECMAScript Parser proposal

[Gareth Heyes]

I had a few goes with making a JS sandbox. I also created a safe DOM 
environment that allowed safe manipulation of innerHTML etc

JS sandbox with regular expressions
http://www.businessinfo.co.uk/labs/jsreg/jsreg.html

JS sandbox and safe DOM environment
http://businessinfo.co.uk/labs/MentalJS/MentalJS.html

It would be great to have a parser in JS!

> On 14 Sep 2019, at 06:46, Jack Works  wrote:
> 
> Just like DOMParser in HTML and Houdini's parser API in CSS, a built-in 
> parser for ECMAScript itself is quite useful in many ways.
> 
> Check out https://github.com/Jack-Works/proposal-ecmascript-parser for 
> details (and also, finding champions!)
> 
> 
> 
> ___
> 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: A new proposal for syntax-checking and sandbox: ECMAScript Parser proposal

[Jack Works]

This proposal is not a part of the binary AST proposal. Because that
proposal wants a binary representation and will not generate AST directly
from the ecmascript spec.
Because run those parsers in browser is pretty slow. Since the JS engine
can already parse the JavaScript code, just expose those interfaces will
make things easier.


Out of curiosity, what is the expected benefit wrt Esprima, Babel or
> Shift? In particular since there is no standard AST for ECMAScript yet [1]?
>
> Cheers,
>  David
>
> [1] Ok, that's a subset of https://github.com/tc39/proposal-binary-ast,
> which is in the pipes.
>
> On 14/09/2019 07:46, Jack Works wrote:
> > Just like DOMParser  in HTML and Houdini's
> > parser API in CSS
> > , a
> > built-in parser for ECMAScript itself is quite useful in many ways.
> >
> > Check out https://github.com/Jack-Works/proposal-ecmascript-parser for
> > details (and also, finding champions!)
> >
> >
> >
> > ___
> > 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: A new proposal for syntax-checking and sandbox: ECMAScript Parser proposal

[David Teller]

Out of curiosity, what is the expected benefit wrt Esprima, Babel or
Shift? In particular since there is no standard AST for ECMAScript yet [1]?

Cheers,
 David

[1] Ok, that's a subset of https://github.com/tc39/proposal-binary-ast,
which is in the pipes.

On 14/09/2019 07:46, Jack Works wrote:
> Just like DOMParser  in HTML and Houdini's
> parser API in CSS
> , a
> built-in parser for ECMAScript itself is quite useful in many ways.
> 
> Check out https://github.com/Jack-Works/proposal-ecmascript-parser for
> details (and also, finding champions!)
> 
> 
> 
> ___
> 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

A new proposal for syntax-checking and sandbox: ECMAScript Parser proposal

[Jack Works]

Just like DOMParser  in HTML and Houdini's parser
API in CSS ,
a built-in parser for ECMAScript itself is quite useful in many ways.

Check out https://github.com/Jack-Works/proposal-ecmascript-parser for
details (and also, finding champions!)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Add new 'Matrix' object

[Isiah Meadows]

Check out the old (and retracted) SIMD.js proposal that aimed to bring SIMD
support to JS and the related offshoot that attempted to cover WebAssembly
interop as well.

https://github.com/tc39/ecmascript_simd
https://github.com/stoklund/portable-simd/blob/master/README.md

Also, WebAssembly has a proposal, spearheaded from that work with JS, to
try to bring SIMD support to it. The WebAssembly proposal is considerably
lower level, but has broad implementor interest.

https://github.com/WebAssembly/simd/blob/master/proposals/simd/SIMD.md

Hardware SIMD and matrices may seem like two entirely different things, but
a large area of overlap exists between small matrix math and CPU vector
instructions. Those instruction sets were designed with coordinate, vector,
and small matrix math in mind. For instance:

- 2x2 matrix multiplication is maybe a dozen or so SSE instructions in
modern Intel x86-64 assembly.
- Scalar matrix multiplication is only a single "multiply vector by scalar"
instruction.
- 2x2 discriminant is a swizzle, a multiply, clear top two lanes, and
horizontal subtract

And even with larger data sets, vector instructions can and do help.
(Consider BLAS.)

On Sun, May 12, 2019 at 05:51 Ed Saleh  wrote:

> Hello,
>
> Matrices are widely used today in in Computer Science, Engineering, and
> AI. I am proposing a new object type of `Matrix([ []... ])` which would
> make working with matrices easier, easily doing operations such matrices
> `multiplication` and `addition`.
>
> Thank you,
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-- 
-

Isiah Meadows
cont...@isiahmeadows.com
www.isiahmeadows.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Add new 'Matrix' object

[kai zhu]

this is wishful thinking, but i've wondered whether [wasm] sqlite3 has
better potential for general-purpose multidimensional vector-operations
than whatever gets spec'ed out in javascript.  probably not, but there's
been research on sql "dot-product-joins" [1].

[1]  Dot-Product Join: Scalable In-Database Linear Algebra for Big Model
Analytics
http://faculty.ucmerced.edu/frusu/Papers/Conference/2017-ssdbm-dot-product-join.pdf


On Tue, May 14, 2019 at 1:24 AM guest271314  wrote:

> A matrix could be viewed as an array of arrays or sets or maps or other
> values. How the values in the arrays or indexes are mapped is dependent
> upon the requirement. The requirement could be to map the networks of this
> entire planet earth; create sets of permutations; create cross word
> puzzles. What is the basic functionality of the Matrix described at this
> proposal?
>
> On Mon, May 13, 2019 at 3:29 PM kai zhu  wrote:
>
>> is that a tentative "no" as in tc39 can't easily spec some low-level
>> linear-algebra primitives that would be useful for both dommatrix, and
>> [gpu-accelerated] tensoflow?
>>
>> i do find value to industry for enhancing client-side performance of 3d
>> visualization and ML.  and i'm starting to see @Ed's original question as
>> whether things like this falls in the scope of javascript language-design
>> (as a fundamental UX-workflow problem), or should remain an
>> embedder/userland concern.
>>
>> -kai
>>
>> On Mon, May 13, 2019 at 3:34 AM David Teller  wrote:
>>
>>> According to the specs, DOMMatrix is limited to 4d matrices. They can be
>>> used to emulate 1d-3d matrices trivially. However, many applications
>>> (e.g. in graph theory) require arbitrary numbers of dimensions.
>>>
>>> I'm not really familiar with Tensorflow, but if I read the API
>>> correctly, it seems to be limited to 1d-5d tensors. If I read the API
>>> correctly, arithmetic operations are tensor operations, rather than
>>> matrix operations, which have very different definitions.
>>>
>>> Cheers,
>>>  David
>>>
>>> On 12/05/2019 21:31, guest271314 wrote:
>>> > Neither ```DOMMatrix``` nor tensorflow functionality are exclusive to
>>> > any single use case. What is the use case of the Matrix object
>>> described
>>> > at this proposal?
>>> ___
>>> 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: Proposal: Add new 'Matrix' object

[guest271314]

A matrix could be viewed as an array of arrays or sets or maps or other
values. How the values in the arrays or indexes are mapped is dependent
upon the requirement. The requirement could be to map the networks of this
entire planet earth; create sets of permutations; create cross word
puzzles. What is the basic functionality of the Matrix described at this
proposal?

On Mon, May 13, 2019 at 3:29 PM kai zhu  wrote:

> is that a tentative "no" as in tc39 can't easily spec some low-level
> linear-algebra primitives that would be useful for both dommatrix, and
> [gpu-accelerated] tensoflow?
>
> i do find value to industry for enhancing client-side performance of 3d
> visualization and ML.  and i'm starting to see @Ed's original question as
> whether things like this falls in the scope of javascript language-design
> (as a fundamental UX-workflow problem), or should remain an
> embedder/userland concern.
>
> -kai
>
> On Mon, May 13, 2019 at 3:34 AM David Teller  wrote:
>
>> According to the specs, DOMMatrix is limited to 4d matrices. They can be
>> used to emulate 1d-3d matrices trivially. However, many applications
>> (e.g. in graph theory) require arbitrary numbers of dimensions.
>>
>> I'm not really familiar with Tensorflow, but if I read the API
>> correctly, it seems to be limited to 1d-5d tensors. If I read the API
>> correctly, arithmetic operations are tensor operations, rather than
>> matrix operations, which have very different definitions.
>>
>> Cheers,
>>  David
>>
>> On 12/05/2019 21:31, guest271314 wrote:
>> > Neither ```DOMMatrix``` nor tensorflow functionality are exclusive to
>> > any single use case. What is the use case of the Matrix object described
>> > at this proposal?
>> ___
>> 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: Proposal: Add new 'Matrix' object

[kai zhu]

is that a tentative "no" as in tc39 can't easily spec some low-level
linear-algebra primitives that would be useful for both dommatrix, and
[gpu-accelerated] tensoflow?

i do find value to industry for enhancing client-side performance of 3d
visualization and ML.  and i'm starting to see @Ed's original question as
whether things like this falls in the scope of javascript language-design
(as a fundamental UX-workflow problem), or should remain an
embedder/userland concern.

-kai

On Mon, May 13, 2019 at 3:34 AM David Teller  wrote:

> According to the specs, DOMMatrix is limited to 4d matrices. They can be
> used to emulate 1d-3d matrices trivially. However, many applications
> (e.g. in graph theory) require arbitrary numbers of dimensions.
>
> I'm not really familiar with Tensorflow, but if I read the API
> correctly, it seems to be limited to 1d-5d tensors. If I read the API
> correctly, arithmetic operations are tensor operations, rather than
> matrix operations, which have very different definitions.
>
> Cheers,
>  David
>
> On 12/05/2019 21:31, guest271314 wrote:
> > Neither ```DOMMatrix``` nor tensorflow functionality are exclusive to
> > any single use case. What is the use case of the Matrix object described
> > at this proposal?
> ___
> 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: Proposal: Add new 'Matrix' object

[David Teller]

According to the specs, DOMMatrix is limited to 4d matrices. They can be
used to emulate 1d-3d matrices trivially. However, many applications
(e.g. in graph theory) require arbitrary numbers of dimensions.

I'm not really familiar with Tensorflow, but if I read the API
correctly, it seems to be limited to 1d-5d tensors. If I read the API
correctly, arithmetic operations are tensor operations, rather than
matrix operations, which have very different definitions.

Cheers,
 David

On 12/05/2019 21:31, guest271314 wrote:
> Neither ```DOMMatrix``` nor tensorflow functionality are exclusive to
> any single use case. What is the use case of the Matrix object described
> at this proposal?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Add new 'Matrix' object

[guest271314]

Neither ```DOMMatrix``` nor tensorflow functionality are exclusive to any
single use case. What is the use case of the Matrix object described at
this proposal?

On Sun, May 12, 2019 at 7:06 PM kai zhu  wrote:

> from what i can tell 1) w3c dommatrix is application-specific to 3d
> visualization and 2) tfjs is application-specific to gpu-accelerated
> machine-learning.
>
> the question is, is it feasible to spec a tc39 "jack-of-all-trades"
> linear-algebra proposal that can underpin the above two (and many other)
> diverse use-cases, w/o ending up being a "master-of-none".
>
> On Sun, May 12, 2019 at 11:20 AM guest271314 
> wrote:
>
>> Is this proposal different from ```DOMMatrix()```
>> https://developer.mozilla.org/en-US/docs/Web/API/DOMMatrix ?
>>
>> On Sun, May 12, 2019 at 9:51 AM Ed Saleh  wrote:
>>
>>> Hello,
>>>
>>> Matrices are widely used today in in Computer Science, Engineering, and
>>> AI. I am proposing a new object type of `Matrix([ []... ])` which would
>>> make working with matrices easier, easily doing operations such matrices
>>> `multiplication` and `addition`.
>>>
>>> Thank you,
>>> ___
>>> 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: Proposal: Add new 'Matrix' object

[kai zhu]

from what i can tell 1) w3c dommatrix is application-specific to 3d
visualization and 2) tfjs is application-specific to gpu-accelerated
machine-learning.

the question is, is it feasible to spec a tc39 "jack-of-all-trades"
linear-algebra proposal that can underpin the above two (and many other)
diverse use-cases, w/o ending up being a "master-of-none".

On Sun, May 12, 2019 at 11:20 AM guest271314  wrote:

> Is this proposal different from ```DOMMatrix()```
> https://developer.mozilla.org/en-US/docs/Web/API/DOMMatrix ?
>
> On Sun, May 12, 2019 at 9:51 AM Ed Saleh  wrote:
>
>> Hello,
>>
>> Matrices are widely used today in in Computer Science, Engineering, and
>> AI. I am proposing a new object type of `Matrix([ []... ])` which would
>> make working with matrices easier, easily doing operations such matrices
>> `multiplication` and `addition`.
>>
>> Thank you,
>> ___
>> 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: Proposal: Add new 'Matrix' object

[guest271314]

Is this proposal different from ```DOMMatrix()```
https://developer.mozilla.org/en-US/docs/Web/API/DOMMatrix ?

On Sun, May 12, 2019 at 9:51 AM Ed Saleh  wrote:

> Hello,
>
> Matrices are widely used today in in Computer Science, Engineering, and
> AI. I am proposing a new object type of `Matrix([ []... ])` which would
> make working with matrices easier, easily doing operations such matrices
> `multiplication` and `addition`.
>
> Thank you,
> ___
> 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: Proposal: Add new 'Matrix' object

[J Decker]

On Sun, May 12, 2019 at 2:51 AM Ed Saleh  wrote:

> Hello,
>
> Matrices are widely used today in in Computer Science, Engineering, and
> AI. I am proposing a new object type of `Matrix([ []... ])` which would
> make working with matrices easier, easily doing operations such matrices
> `multiplication` and `addition`.
>
> There is a pretty good library for that...
https://js.tensorflow.org/api/latest/#Operations-Arithmetic
:)
they call them 'tensors' though.


> Thank you,
> ___
> 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: Proposal: Add new 'Matrix' object

[kai zhu]

@ed, general-purpose matrix-ops work poorly with malformed data like ```[1.2, 
null, 4.234]``` which are ubiquitous in ux-workflow programming.  my experience 
in javascript linear-algebra mostly devolves to writing divide-by-zero 
"technical-debt" that's non-reusable/application-specific.  it ends up more 
cost-efficient for me to write custom for-loops, with malformed-data checks 
embedded in them.

> On 12 May 2019, at 04:50, Ed Saleh  wrote:
> 
> Hello, 
> 
> Matrices are widely used today in in Computer Science, Engineering, and AI. I 
> am proposing a new object type of `Matrix([ []... ])` which would make 
> working with matrices easier, easily doing operations such matrices 
> `multiplication` and `addition`. 
> 
> Thank you, 
> ___
> 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

Proposal: Add new 'Matrix' object

[Ed Saleh]

Hello,

Matrices are widely used today in in Computer Science, Engineering, and AI. I 
am proposing a new object type of `Matrix([ []... ])` which would make working 
with matrices easier, easily doing operations such matrices `multiplication` 
and `addition`.

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

Re: Re: New Proposal: Number.range (Yes, range again)

[Ed Saleh]

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

Re: Proposal For A New Alternative Keyword To “this” For Classes

[Michael Luder-Rosefield]

I'm getting deja vu again

On Tue, 19 Mar 2019 at 14:31 Isiah Meadows  wrote:

> UX workflows aren't all of JS. Classes exist for many more reasons than
> that, and 99% of my classes are for abstracting non-trivial business logic
> and ensuring *those* are easily testable, not directly UI/UX.
>
> -
>
> Isiah Meadows
> cont...@isiahmeadows.com
> www.isiahmeadows.com
>
>
> On Sun, Mar 17, 2019 at 2:35 AM kai zhu  wrote:
>
>> *rant warning*
>>
>> -1 because classes generally have little-value in UX-workflow programming.
>>
>> the example class RequestManager (given in this discussion),
>> realistically has little reusability-value -- its no better than employing
>> a throwaway static-function (both are equally likely to get rewritten each
>> time UX-workflow features are added.).
>>
>> for example, a common feature-request is adding visual-progress-bar.
>>  there is no "simple" way to extend RequestManager to do this, other than
>> significant-refactoring of the base-class (and risk breaking
>> class-dependencies downstream).
>>
>> some other common UX feature-requests that would likely invalidate
>> "reusability" of your class-based design include:
>>
>> 1. needing to upload a binary-file (social-images, receipt-signatures,
>> screenshots, etc...)
>> 2. needing to upload multiple binary-files in parallel (keeping track of
>> timeouts of each)
>> 3. needing to upload multiple binary-files in parallel (keeping track of
>> timeouts of each),
>> and then download their thumbnail-previews from server to visually
>> confirm uploads were correct
>> 4. needing to make parallel http-requests from 3rd-party sources and
>> "joining" the response-data
>> 5. needing the sign-up-page to additionally pre-validate
>> email / username / mobile-number / credit-card / etc... before
>> form-submission to server
>>
>> many frontend-engineers with experience "extending" products with
>> additional UX-workflow features, know its rarely as simple as modifying
>> some class-methods and be done with it -- it oftentimes require rewriting
>> nearly every-piece-of-code that touches the given workflow needing
>> enhancement.
>>
>> p.s. -- here's a "simple" fully-working UX-example [1] on how to add
>> visual-progress-bar to http-requests.  if i had to additionally add some of
>> the other UX-features mentioned above, it would likely entail me completely
>> rewriting the throwaway static-function, rather than waste time trying to
>> extend it.
>>
>> [1] https://jsfiddle.net/kaizhu256/t9ubdenf/
>>
>> ```html
>> 
>> /* jslint utility2:true */
>> /* csslint ignore:start */
>> *,
>> *:after,
>> *:before {
>> box-sizing: border-box;
>> }
>> /* csslint ignore:end */
>> body {
>> background: #eee;
>> font-family: Arial, Helvetica, sans-serif;
>> font-size: small;
>> }
>> input {
>> width: 100%;
>> }
>> textarea {
>> font-family: Consolas, Menlo, monospace;
>> font-size: smaller;
>> overflow: auto;
>> width: 100%;
>> }
>> 
>>
>> 
>>
>> ajax-request
>> {
>> "method": "GET",
>> "url": "https://api.github.com/orgs/octokit/repos";,
>> "headers": {
>> "accept": "application/vnd.github.v3+json"
>> },
>> "data": "hello world!"
>> }
>>
>> submit ajax-request
>>
>> ajax-response
>> 
>>
>> 
>> /*jslint browser*/
>> (function () {
>> "use strict";
>> var local;
>> local = {};
>> window.local = local;
>>
>> local.ajax = function (opt, onError) {
>> /*
>>  * simple, throwaway ajax-function that can be easily rewritten
>>  * to accomodate new [async] ux-features
>>  */
>> var resHandler;
>> var xhr;
>> opt.headers = opt.headers || {};
>> opt.method = opt.method || "GET";
>> xhr = new XMLHttpRequest();
>> // open url
>> xhr.open(opt.method, opt.url);
>> // set req-headers
>> Object.entries(opt.headers).forEach(function (entry) {
>> xhr.setRequestHeader(entry[0], entry[1]);
>> });
>> // send data
>> xhr.send(opt.data);
>>  

Re: Proposal For A New Alternative Keyword To “this” For Classes

[Isiah Meadows]

UX workflows aren't all of JS. Classes exist for many more reasons than
that, and 99% of my classes are for abstracting non-trivial business logic
and ensuring *those* are easily testable, not directly UI/UX.

-

Isiah Meadows
cont...@isiahmeadows.com
www.isiahmeadows.com


On Sun, Mar 17, 2019 at 2:35 AM kai zhu  wrote:

> *rant warning*
>
> -1 because classes generally have little-value in UX-workflow programming.
>
> the example class RequestManager (given in this discussion), realistically
> has little reusability-value -- its no better than employing a throwaway
> static-function (both are equally likely to get rewritten each time
> UX-workflow features are added.).
>
> for example, a common feature-request is adding visual-progress-bar.
>  there is no "simple" way to extend RequestManager to do this, other than
> significant-refactoring of the base-class (and risk breaking
> class-dependencies downstream).
>
> some other common UX feature-requests that would likely invalidate
> "reusability" of your class-based design include:
>
> 1. needing to upload a binary-file (social-images, receipt-signatures,
> screenshots, etc...)
> 2. needing to upload multiple binary-files in parallel (keeping track of
> timeouts of each)
> 3. needing to upload multiple binary-files in parallel (keeping track of
> timeouts of each),
> and then download their thumbnail-previews from server to visually
> confirm uploads were correct
> 4. needing to make parallel http-requests from 3rd-party sources and
> "joining" the response-data
> 5. needing the sign-up-page to additionally pre-validate
> email / username / mobile-number / credit-card / etc... before
> form-submission to server
>
> many frontend-engineers with experience "extending" products with
> additional UX-workflow features, know its rarely as simple as modifying
> some class-methods and be done with it -- it oftentimes require rewriting
> nearly every-piece-of-code that touches the given workflow needing
> enhancement.
>
> p.s. -- here's a "simple" fully-working UX-example [1] on how to add
> visual-progress-bar to http-requests.  if i had to additionally add some of
> the other UX-features mentioned above, it would likely entail me completely
> rewriting the throwaway static-function, rather than waste time trying to
> extend it.
>
> [1] https://jsfiddle.net/kaizhu256/t9ubdenf/
>
> ```html
> 
> /* jslint utility2:true */
> /* csslint ignore:start */
> *,
> *:after,
> *:before {
> box-sizing: border-box;
> }
> /* csslint ignore:end */
> body {
> background: #eee;
> font-family: Arial, Helvetica, sans-serif;
> font-size: small;
> }
> input {
> width: 100%;
> }
> textarea {
> font-family: Consolas, Menlo, monospace;
> font-size: smaller;
> overflow: auto;
> width: 100%;
> }
> 
>
> 
>
> ajax-request
> {
> "method": "GET",
> "url": "https://api.github.com/orgs/octokit/repos";,
> "headers": {
> "accept": "application/vnd.github.v3+json"
> },
> "data": "hello world!"
> }
>
> submit ajax-request
>
> ajax-response
> 
>
> 
> /*jslint browser*/
> (function () {
> "use strict";
> var local;
> local = {};
> window.local = local;
>
> local.ajax = function (opt, onError) {
> /*
>  * simple, throwaway ajax-function that can be easily rewritten
>  * to accomodate new [async] ux-features
>  */
> var resHandler;
> var xhr;
> opt.headers = opt.headers || {};
> opt.method = opt.method || "GET";
> xhr = new XMLHttpRequest();
> // open url
> xhr.open(opt.method, opt.url);
> // set req-headers
> Object.entries(opt.headers).forEach(function (entry) {
> xhr.setRequestHeader(entry[0], entry[1]);
> });
> // send data
> xhr.send(opt.data);
> // init request-handling
> resHandler = function (evt) {
> /*
>  * this function will handle ajax-response
>  */
> switch (evt.type) {
> case "abort":
> case "error":
> // decrement ajaxProgressCounter
> local.ajaxProgressCounter = Math.max(
> local.ajaxProgressCounter - 1,
> 0
> );
> onError(new Error(evt.type), xhr);
> break;
> case "l

Re: Proposal For A New Alternative Keyword To “this” For Classes

[Isiah Meadows]

Assuming Babel can get ahold of unmodified builtins, even if it's only
during `@babel/runtime` initialization, it could still break that wrapper.
`core-js` itself uses this trick extensively to dodge otherwise observable
side effects in all of its wrappers. 😉

(Babel *might* be invoking `wm.get(this)` and `wm.set(this)`, but it should
really be binding those on initialization where possible.)
On Tue, Mar 12, 2019 at 14:36 Ranando King  wrote:

> @Isiah Remember, the class-fields proposal has absorbed the private-fields
> proposal, and it is those private fields that have no precise equivalent.
> WeakMap and closures can approximate what private fields do. However,
> private fields has semantics and capabilities that cannot be fully
> reproduced in current ES. For instance, I can wrap both WeakMap and Proxy
> in a way that Babel private-fields will be proxy safe. With native private
> fields, that's impossible.
>
> On Tue, Mar 12, 2019 at 10:39 AM Isiah Meadows 
> wrote:
>
>> @Ranando Minor nit: class fields can be purely implemented in terms of
>> `defineProperty` (for public) and weak maps (for private - what's used
>> today for private data). Private methods could be implemented in terms of
>> weak sets/maps and an object with methods outside the class's scope.
>> Private static properties could just verify `this === Type`.
>>
>> So no, those don't quite reify classes, either. (If something can be
>> fully transpiled or polyfilled, it doesn't create or reify any new
>> primitives.)
>>
>> On Tue, Mar 12, 2019 at 09:51 Ranando King  wrote:
>>
>>> I get what you're after. I touched on the same things when creating my
>>> private members proposal. The best of approaches for what you want is
>>> indeed relying on the lexical scope to act as a binding for all class
>>> members. There's just a couple of problems with doing things that way:
>>>
>>> 1. ES is a dynamic language. This makes lexical binding difficult
>>> because it's entirely possible to call a non-static class method where
>>> *this* is undefined or null. Not allowing for that scenario will break
>>> existing code. Allowing for that scenario will cause variables to be
>>> unexpectedly either written to the global scope or throw.
>>> 2. Class isn't really a "thing" in ES, at least, it isn't until
>>> class-fields lands. The use of the *class* keyword is currently
>>> completely optional. There's nothing in current ES that you can do with
>>> *class* that can't be done without it except use the *super()* call in
>>> the constructor function. But even that can be substituted with
>>> *Reflect.construct*(). Class-fields will destroy this symmetry, making
>>> *class* it's own unique "thing". But until then, what do you do about
>>> all the "classes" that don't use the *class* keyword?
>>>
>>> Long and short, this means both the lexical scope approach and the
>>> alternate keyword approach will either break existing code or bring
>>> dubious-to-no benefit.
>>>
>>> On Tue, Mar 12, 2019 at 3:06 AM john larson 
>>> wrote:
>>>
>>>> So in terms of implementation, may be having instance method/property
>>>> references on the objects and having static method/property references on
>>>> the prototype is the solution?
>>>>
>>>> On Tue, Mar 12, 2019 at 8:14 AM Isiah Meadows 
>>>> wrote:
>>>>
>>>>> I've done a little engine work, and inline caches work by inline type
>>>>> maps based on the callee site. This *can* be used to reconstruct values +
>>>>> receivers, but only when the value is constant. It is not sufficient to
>>>>> ensure identity remains the same, and engines would still need a weak map
>>>>> to link methods to instances (as opposed to prototypes).
>>>>>
>>>>> It's worth noting not even Java or Ruby offers this - their method
>>>>> references/objects (like our bound functions) are *not* memoized - they're
>>>>> linked to classes, not instances. Python is the exception here in
>>>>> auto-binding instance methods, not the norm.
>>>>> On Mon, Mar 11, 2019 at 15:37 Bergi  wrote:
>>>>>
>>>>>> Hi John!
>>>>>> > I think the js run-time already has that information at hand, so as
>>>>>> > long as we don't implement this as pure syntactical sugar,

Re: Proposal For A New Alternative Keyword To “this” For Classes

[guest271314]

```class RequestManager {
  __THIS__(method) {
return new Proxy(method, {
  apply: (target, thisArg, argumentsList) => {
return method.apply(thisArg, [...argumentsList, {
  THIS: this
}])
  }
})
  }
  constructor() {
this.successMessage = "Xhr successful.";
  }
  makeRequest() {
    var oReq = new XMLHttpRequest();
oReq.addEventListener("load", this.__THIS__(this.responseHandler));
oReq.open("GET", "data:,");
oReq.send();
  }

  responseHandler(e, {THIS} = {}) {
console.log(this, e);
window.alert(THIS.successMessage)
  }
}

var reqManager = new RequestManager();

reqManager.makeRequest();```

On Mon, Mar 11, 2019 at 8:59 AM john larson 
wrote:

> First of all, thank you all for taking the time to review the proposal and
> sharing your valuable opinions. I would like to note that the proposal aims
> not to add a new capability that was not possible to do before but rather
> move the standard forward on the way for a modern, better and easier to use
> language for all the developers. Advancements of the language, or any
> language in that matter, throughout the last decade also followed a similar
> path because we were already able to do everything in one way or the other.
> We actually strive for the same thing, a better Javascript.
>
>
>
> That being said, let me try to clarify my proposal further by walking you
> through my thought process:
>
>
>
> Normally if I try to write a class similar to the sample code I have given
> in my first email using an object oriented programming language like Java,
> C# etc., I would be writing something similar to the following:
>
>
>
> class RequestManager
>
> {
>
>     string successMessage = "Xhr successful.";
>
>
>
> void makeRequest()
>
> {
>
> var oReq = new XMLHttpRequest();
>
> oReq.addEventListener("load", responseHandler);
>
> oReq.open("GET", "*www.google.com*
> <#m_-847355274947397_inbox/_blank>");
>
> oReq.send();
>
> }
>
>
>
> void responseHandler()
>
> {
>
> window.alert(successMessage);
>
> }
>
> }
>
>
>
> As you can see, I do not even have to use a special keyword for referring
> to methods from inside the class. Because they are already in lexical
> scope. Now, if this can be accomplished in Javascript without hitting
> some limitation/restriction due to the current state of the language, I
> think it would be the ideal solution. (This limitation might be the class
> syntax being just a syntactical sugar or some other reason that I cannot
> foresee right now and that would require a breaking change.) And I would
> happily change the proposal that way: “A no-keyword alternative for the
> “this””. If I should summarize this approach, I can say that every method
> of the class is going to assume the behavior we now have with arrow
> functions, but without requiring the use of the “this” and the arrow
> function syntax.
>
>
>
> As contrary to the ideal solution, the last thing I would want would be to
> use a context-dependant keyword like the “this” to refer to
> methods/properties of the object and then try to set the context right by
> using binding or arrow functions. This referral should be lexical, not
> context-dependant. If I have the intent of referring to the instance
> method/property, that intent should manifest itself right there where I am
> using this method/property. I shouldn’t be looking at if this takes place
> inside an arrow function, or if the enclosing method is called with a
> binding or not. Why should I care about the enclosing of the call, right?
>
> By the way, MDN also mentions the following about the use of arrow
> functions: “Arrow function expressions are ill suited as methods”.
>
> *@Yulia:* Thanks for pointing out the decorator approach. But that also
> seems to deal with the enclosing and tries to solve the problem with a
> “context binding” approach. The only difference is the way it determines
> the binding. I am against this binding approach all together. Only the
> lexical scope of the code should be taken into consideration.
>
>
>
> So far, I have laid out what I think the ideal solution is and what I
> think the problematic state we are in right now. And as a middle-ground,
> in case the ideal solution cannot be applied, I proposed a new keyword to
> use instead of the “this” so that it will always refer to the instance,
> regardless of execution context binding. In which case, when you replace
> the “this” in the problematic sampl

Re: Proposal For A New Alternative Keyword To “this” For Classes

[Ranando King]

@Isiah Remember, the class-fields proposal has absorbed the private-fields
proposal, and it is those private fields that have no precise equivalent.
WeakMap and closures can approximate what private fields do. However,
private fields has semantics and capabilities that cannot be fully
reproduced in current ES. For instance, I can wrap both WeakMap and Proxy
in a way that Babel private-fields will be proxy safe. With native private
fields, that's impossible.

On Tue, Mar 12, 2019 at 10:39 AM Isiah Meadows 
wrote:

> @Ranando Minor nit: class fields can be purely implemented in terms of
> `defineProperty` (for public) and weak maps (for private - what's used
> today for private data). Private methods could be implemented in terms of
> weak sets/maps and an object with methods outside the class's scope.
> Private static properties could just verify `this === Type`.
>
> So no, those don't quite reify classes, either. (If something can be fully
> transpiled or polyfilled, it doesn't create or reify any new primitives.)
>
> On Tue, Mar 12, 2019 at 09:51 Ranando King  wrote:
>
>> I get what you're after. I touched on the same things when creating my
>> private members proposal. The best of approaches for what you want is
>> indeed relying on the lexical scope to act as a binding for all class
>> members. There's just a couple of problems with doing things that way:
>>
>> 1. ES is a dynamic language. This makes lexical binding difficult because
>> it's entirely possible to call a non-static class method where *this* is
>> undefined or null. Not allowing for that scenario will break existing code.
>> Allowing for that scenario will cause variables to be unexpectedly either
>> written to the global scope or throw.
>> 2. Class isn't really a "thing" in ES, at least, it isn't until
>> class-fields lands. The use of the *class* keyword is currently
>> completely optional. There's nothing in current ES that you can do with
>> *class* that can't be done without it except use the *super()* call in
>> the constructor function. But even that can be substituted with
>> *Reflect.construct*(). Class-fields will destroy this symmetry, making
>> *class* it's own unique "thing". But until then, what do you do about
>> all the "classes" that don't use the *class* keyword?
>>
>> Long and short, this means both the lexical scope approach and the
>> alternate keyword approach will either break existing code or bring
>> dubious-to-no benefit.
>>
>> On Tue, Mar 12, 2019 at 3:06 AM john larson 
>> wrote:
>>
>>> So in terms of implementation, may be having instance method/property
>>> references on the objects and having static method/property references on
>>> the prototype is the solution?
>>>
>>> On Tue, Mar 12, 2019 at 8:14 AM Isiah Meadows 
>>> wrote:
>>>
>>>> I've done a little engine work, and inline caches work by inline type
>>>> maps based on the callee site. This *can* be used to reconstruct values +
>>>> receivers, but only when the value is constant. It is not sufficient to
>>>> ensure identity remains the same, and engines would still need a weak map
>>>> to link methods to instances (as opposed to prototypes).
>>>>
>>>> It's worth noting not even Java or Ruby offers this - their method
>>>> references/objects (like our bound functions) are *not* memoized - they're
>>>> linked to classes, not instances. Python is the exception here in
>>>> auto-binding instance methods, not the norm.
>>>> On Mon, Mar 11, 2019 at 15:37 Bergi  wrote:
>>>>
>>>>> Hi John!
>>>>> > I think the js run-time already has that information at hand, so as
>>>>> > long as we don't implement this as pure syntactical sugar, there
>>>>> would
>>>>> > not be a need to keep an extra reference to anything, because it
>>>>> would
>>>>> > be already there. The run-time will know which instance the invoked
>>>>> > method belongs to.
>>>>>
>>>>> Well no, you're wrong here: the runtime does not have this information
>>>>> at hand. In your example (simplified)
>>>>> ```
>>>>> var reqManager = new RequestManager();
>>>>> function addEventListener(f) {
>>>>>  console.log(f);
>>>>>  f(event);
>>>>> }
>>>>> addEventListener(reqManager.r

Re: Proposal For A New Alternative Keyword To “this” For Classes

[Isiah Meadows]

@Ranando Minor nit: class fields can be purely implemented in terms of
`defineProperty` (for public) and weak maps (for private - what's used
today for private data). Private methods could be implemented in terms of
weak sets/maps and an object with methods outside the class's scope.
Private static properties could just verify `this === Type`.

So no, those don't quite reify classes, either. (If something can be fully
transpiled or polyfilled, it doesn't create or reify any new primitives.)

On Tue, Mar 12, 2019 at 09:51 Ranando King  wrote:

> I get what you're after. I touched on the same things when creating my
> private members proposal. The best of approaches for what you want is
> indeed relying on the lexical scope to act as a binding for all class
> members. There's just a couple of problems with doing things that way:
>
> 1. ES is a dynamic language. This makes lexical binding difficult because
> it's entirely possible to call a non-static class method where *this* is
> undefined or null. Not allowing for that scenario will break existing code.
> Allowing for that scenario will cause variables to be unexpectedly either
> written to the global scope or throw.
> 2. Class isn't really a "thing" in ES, at least, it isn't until
> class-fields lands. The use of the *class* keyword is currently
> completely optional. There's nothing in current ES that you can do with
> *class* that can't be done without it except use the *super()* call in
> the constructor function. But even that can be substituted with
> *Reflect.construct*(). Class-fields will destroy this symmetry, making
> *class* it's own unique "thing". But until then, what do you do about all
> the "classes" that don't use the *class* keyword?
>
> Long and short, this means both the lexical scope approach and the
> alternate keyword approach will either break existing code or bring
> dubious-to-no benefit.
>
> On Tue, Mar 12, 2019 at 3:06 AM john larson 
> wrote:
>
>> So in terms of implementation, may be having instance method/property
>> references on the objects and having static method/property references on
>> the prototype is the solution?
>>
>> On Tue, Mar 12, 2019 at 8:14 AM Isiah Meadows 
>> wrote:
>>
>>> I've done a little engine work, and inline caches work by inline type
>>> maps based on the callee site. This *can* be used to reconstruct values +
>>> receivers, but only when the value is constant. It is not sufficient to
>>> ensure identity remains the same, and engines would still need a weak map
>>> to link methods to instances (as opposed to prototypes).
>>>
>>> It's worth noting not even Java or Ruby offers this - their method
>>> references/objects (like our bound functions) are *not* memoized - they're
>>> linked to classes, not instances. Python is the exception here in
>>> auto-binding instance methods, not the norm.
>>> On Mon, Mar 11, 2019 at 15:37 Bergi  wrote:
>>>
>>>> Hi John!
>>>> > I think the js run-time already has that information at hand, so as
>>>> > long as we don't implement this as pure syntactical sugar, there would
>>>> > not be a need to keep an extra reference to anything, because it would
>>>> > be already there. The run-time will know which instance the invoked
>>>> > method belongs to.
>>>>
>>>> Well no, you're wrong here: the runtime does not have this information
>>>> at hand. In your example (simplified)
>>>> ```
>>>> var reqManager = new RequestManager();
>>>> function addEventListener(f) {
>>>>  console.log(f);
>>>>  f(event);
>>>> }
>>>> addEventListener(reqManager.responseHandler);
>>>> ```
>>>> the `addEventListener` function will not know that the function `f` you
>>>> passed was a method of the `reqManager` instance. It cannot distinguish
>>>> that call from
>>>> ```
>>>> addEventListener(RequestManager.prototype.responseHandler);
>>>> ```
>>>> or
>>>> ```
>>>> var g = otherReqManager.responseHandler;
>>>> addEventListener(g);
>>>> ```
>>>>
>>>> It is exactly the same function that is passed in all three cases. There
>>>> is no instance bound to `f`, and `f(event)` will not invoke it as a
>>>> method (with a receiver/`this` value).
>>>>
>>>> Best regards,
>>>>   Bergi
>>>> ___
>>>> 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: Proposal For A New Alternative Keyword To “this” For Classes

[Isiah Meadows]

@John May I suggest you play around a little with Lua? That language is
prototype-based like JS, with several similar idioms, but it's a lot
simpler, without `new`, property descriptors, or the like. Like JS, it also
has a keyword `self` equivalent to JS `this` and inheritance is purely
prototype-based. Unlike JS, it has no sugar for small functions nor does it
have sugar for class-like constructs - it's like ES5 in that respect. Once
you understand how prototypes work and how they're fundamentally different
from classes, it will help you understand why method references, in the way
you're describing them, don't make sense in that model.
On Tue, Mar 12, 2019 at 09:51 Ranando King  wrote:

> I get what you're after. I touched on the same things when creating my
> private members proposal. The best of approaches for what you want is
> indeed relying on the lexical scope to act as a binding for all class
> members. There's just a couple of problems with doing things that way:
>
> 1. ES is a dynamic language. This makes lexical binding difficult because
> it's entirely possible to call a non-static class method where *this* is
> undefined or null. Not allowing for that scenario will break existing code.
> Allowing for that scenario will cause variables to be unexpectedly either
> written to the global scope or throw.
> 2. Class isn't really a "thing" in ES, at least, it isn't until
> class-fields lands. The use of the *class* keyword is currently
> completely optional. There's nothing in current ES that you can do with
> *class* that can't be done without it except use the *super()* call in
> the constructor function. But even that can be substituted with
> *Reflect.construct*(). Class-fields will destroy this symmetry, making
> *class* it's own unique "thing". But until then, what do you do about all
> the "classes" that don't use the *class* keyword?
>
> Long and short, this means both the lexical scope approach and the
> alternate keyword approach will either break existing code or bring
> dubious-to-no benefit.
>
> On Tue, Mar 12, 2019 at 3:06 AM john larson 
> wrote:
>
>> So in terms of implementation, may be having instance method/property
>> references on the objects and having static method/property references on
>> the prototype is the solution?
>>
>> On Tue, Mar 12, 2019 at 8:14 AM Isiah Meadows 
>> wrote:
>>
>>> I've done a little engine work, and inline caches work by inline type
>>> maps based on the callee site. This *can* be used to reconstruct values +
>>> receivers, but only when the value is constant. It is not sufficient to
>>> ensure identity remains the same, and engines would still need a weak map
>>> to link methods to instances (as opposed to prototypes).
>>>
>>> It's worth noting not even Java or Ruby offers this - their method
>>> references/objects (like our bound functions) are *not* memoized - they're
>>> linked to classes, not instances. Python is the exception here in
>>> auto-binding instance methods, not the norm.
>>> On Mon, Mar 11, 2019 at 15:37 Bergi  wrote:
>>>
>>>> Hi John!
>>>> > I think the js run-time already has that information at hand, so as
>>>> > long as we don't implement this as pure syntactical sugar, there would
>>>> > not be a need to keep an extra reference to anything, because it would
>>>> > be already there. The run-time will know which instance the invoked
>>>> > method belongs to.
>>>>
>>>> Well no, you're wrong here: the runtime does not have this information
>>>> at hand. In your example (simplified)
>>>> ```
>>>> var reqManager = new RequestManager();
>>>> function addEventListener(f) {
>>>>  console.log(f);
>>>>  f(event);
>>>> }
>>>> addEventListener(reqManager.responseHandler);
>>>> ```
>>>> the `addEventListener` function will not know that the function `f` you
>>>> passed was a method of the `reqManager` instance. It cannot distinguish
>>>> that call from
>>>> ```
>>>> addEventListener(RequestManager.prototype.responseHandler);
>>>> ```
>>>> or
>>>> ```
>>>> var g = otherReqManager.responseHandler;
>>>> addEventListener(g);
>>>> ```
>>>>
>>>> It is exactly the same function that is passed in all three cases. There
>>>> is no instance bound to `f`, and `f(event)` will not invoke it as a
>>>> method (with a receiver/`this` value).
>>>>
>>>> Best regards,
>>>>   Bergi
>>>> ___
>>>> 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: Proposal For A New Alternative Keyword To “this” For Classes

[Ranando King]

I get what you're after. I touched on the same things when creating my
private members proposal. The best of approaches for what you want is
indeed relying on the lexical scope to act as a binding for all class
members. There's just a couple of problems with doing things that way:

1. ES is a dynamic language. This makes lexical binding difficult because
it's entirely possible to call a non-static class method where *this* is
undefined or null. Not allowing for that scenario will break existing code.
Allowing for that scenario will cause variables to be unexpectedly either
written to the global scope or throw.
2. Class isn't really a "thing" in ES, at least, it isn't until
class-fields lands. The use of the *class* keyword is currently completely
optional. There's nothing in current ES that you can do with *class* that
can't be done without it except use the *super()* call in the constructor
function. But even that can be substituted with *Reflect.construct*().
Class-fields will destroy this symmetry, making *class* it's own unique
"thing". But until then, what do you do about all the "classes" that don't
use the *class* keyword?

Long and short, this means both the lexical scope approach and the
alternate keyword approach will either break existing code or bring
dubious-to-no benefit.

On Tue, Mar 12, 2019 at 3:06 AM john larson 
wrote:

> So in terms of implementation, may be having instance method/property
> references on the objects and having static method/property references on
> the prototype is the solution?
>
> On Tue, Mar 12, 2019 at 8:14 AM Isiah Meadows 
> wrote:
>
>> I've done a little engine work, and inline caches work by inline type
>> maps based on the callee site. This *can* be used to reconstruct values +
>> receivers, but only when the value is constant. It is not sufficient to
>> ensure identity remains the same, and engines would still need a weak map
>> to link methods to instances (as opposed to prototypes).
>>
>> It's worth noting not even Java or Ruby offers this - their method
>> references/objects (like our bound functions) are *not* memoized - they're
>> linked to classes, not instances. Python is the exception here in
>> auto-binding instance methods, not the norm.
>> On Mon, Mar 11, 2019 at 15:37 Bergi  wrote:
>>
>>> Hi John!
>>> > I think the js run-time already has that information at hand, so as
>>> > long as we don't implement this as pure syntactical sugar, there would
>>> > not be a need to keep an extra reference to anything, because it would
>>> > be already there. The run-time will know which instance the invoked
>>> > method belongs to.
>>>
>>> Well no, you're wrong here: the runtime does not have this information
>>> at hand. In your example (simplified)
>>> ```
>>> var reqManager = new RequestManager();
>>> function addEventListener(f) {
>>>  console.log(f);
>>>  f(event);
>>> }
>>> addEventListener(reqManager.responseHandler);
>>> ```
>>> the `addEventListener` function will not know that the function `f` you
>>> passed was a method of the `reqManager` instance. It cannot distinguish
>>> that call from
>>> ```
>>> addEventListener(RequestManager.prototype.responseHandler);
>>> ```
>>> or
>>> ```
>>> var g = otherReqManager.responseHandler;
>>> addEventListener(g);
>>> ```
>>>
>>> It is exactly the same function that is passed in all three cases. There
>>> is no instance bound to `f`, and `f(event)` will not invoke it as a
>>> method (with a receiver/`this` value).
>>>
>>> Best regards,
>>>   Bergi
>>> ___
>>> 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: Proposal For A New Alternative Keyword To “this” For Classes

[john larson]

So in terms of implementation, may be having instance method/property
references on the objects and having static method/property references on
the prototype is the solution?

On Tue, Mar 12, 2019 at 8:14 AM Isiah Meadows 
wrote:

> I've done a little engine work, and inline caches work by inline type maps
> based on the callee site. This *can* be used to reconstruct values +
> receivers, but only when the value is constant. It is not sufficient to
> ensure identity remains the same, and engines would still need a weak map
> to link methods to instances (as opposed to prototypes).
>
> It's worth noting not even Java or Ruby offers this - their method
> references/objects (like our bound functions) are *not* memoized - they're
> linked to classes, not instances. Python is the exception here in
> auto-binding instance methods, not the norm.
> On Mon, Mar 11, 2019 at 15:37 Bergi  wrote:
>
>> Hi John!
>> > I think the js run-time already has that information at hand, so as
>> > long as we don't implement this as pure syntactical sugar, there would
>> > not be a need to keep an extra reference to anything, because it would
>> > be already there. The run-time will know which instance the invoked
>> > method belongs to.
>>
>> Well no, you're wrong here: the runtime does not have this information
>> at hand. In your example (simplified)
>> ```
>> var reqManager = new RequestManager();
>> function addEventListener(f) {
>>  console.log(f);
>>  f(event);
>> }
>> addEventListener(reqManager.responseHandler);
>> ```
>> the `addEventListener` function will not know that the function `f` you
>> passed was a method of the `reqManager` instance. It cannot distinguish
>> that call from
>> ```
>> addEventListener(RequestManager.prototype.responseHandler);
>> ```
>> or
>> ```
>> var g = otherReqManager.responseHandler;
>> addEventListener(g);
>> ```
>>
>> It is exactly the same function that is passed in all three cases. There
>> is no instance bound to `f`, and `f(event)` will not invoke it as a
>> method (with a receiver/`this` value).
>>
>> Best regards,
>>   Bergi
>> ___
>> 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: Proposal For A New Alternative Keyword To “this” For Classes

[Isiah Meadows]

I've done a little engine work, and inline caches work by inline type maps
based on the callee site. This *can* be used to reconstruct values +
receivers, but only when the value is constant. It is not sufficient to
ensure identity remains the same, and engines would still need a weak map
to link methods to instances (as opposed to prototypes).

It's worth noting not even Java or Ruby offers this - their method
references/objects (like our bound functions) are *not* memoized - they're
linked to classes, not instances. Python is the exception here in
auto-binding instance methods, not the norm.
On Mon, Mar 11, 2019 at 15:37 Bergi  wrote:

> Hi John!
> > I think the js run-time already has that information at hand, so as
> > long as we don't implement this as pure syntactical sugar, there would
> > not be a need to keep an extra reference to anything, because it would
> > be already there. The run-time will know which instance the invoked
> > method belongs to.
>
> Well no, you're wrong here: the runtime does not have this information
> at hand. In your example (simplified)
> ```
> var reqManager = new RequestManager();
> function addEventListener(f) {
>  console.log(f);
>  f(event);
> }
> addEventListener(reqManager.responseHandler);
> ```
> the `addEventListener` function will not know that the function `f` you
> passed was a method of the `reqManager` instance. It cannot distinguish
> that call from
> ```
> addEventListener(RequestManager.prototype.responseHandler);
> ```
> or
> ```
> var g = otherReqManager.responseHandler;
> addEventListener(g);
> ```
>
> It is exactly the same function that is passed in all three cases. There
> is no instance bound to `f`, and `f(event)` will not invoke it as a
> method (with a receiver/`this` value).
>
> Best regards,
>   Bergi
> ___
> 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: Proposal For A New Alternative Keyword To “this” For Classes

[Bergi]

Hi John!

I think the js run-time already has that information at hand, so as
long as we don't implement this as pure syntactical sugar, there would
not be a need to keep an extra reference to anything, because it would
be already there. The run-time will know which instance the invoked
method belongs to.


Well no, you're wrong here: the runtime does not have this information
at hand. In your example (simplified)
```
var reqManager = new RequestManager();
function addEventListener(f) {
console.log(f);
f(event);
}
addEventListener(reqManager.responseHandler);
```
the `addEventListener` function will not know that the function `f` you
passed was a method of the `reqManager` instance. It cannot distinguish
that call from
```
addEventListener(RequestManager.prototype.responseHandler);
```
or
```
var g = otherReqManager.responseHandler;
addEventListener(g);
```

It is exactly the same function that is passed in all three cases. There
is no instance bound to `f`, and `f(event)` will not invoke it as a
method (with a receiver/`this` value).

Best regards,
 Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal For A New Alternative Keyword To “this” For Classes

[Ben Wiley]

Whatever the implementation, I'd be surprised to learn that the browser
*does* have the information automatically and wouldn't need to store
additional memory similar to .bind().

But I'm also not a browser engine expert, so there's that.

Le lun. 11 mars 2019 11 h 55, john larson  a
écrit :

> Well, actually this is the same discussion we had with *@Jordan Harband. *I
> think the js run-time already has that information at hand, so as long as
> we don't implement this as pure syntactical sugar, there would not be a
> need to keep an extra reference to anything, because it would be already
> there. The run-time will know which instance the invoked method belongs
> to. But as I said, it would be insightful to get a js engine expert opinion
> on this. Having said that, I believe it is just an implementation detail
> and can be handled one way or the other. I guess the “class property
> arrow methods in React" example you just provided also supports this
> notion.
>
> On Mon, Mar 11, 2019 at 6:23 PM Ben Wiley 
> wrote:
>
>> The main issue here is that you're sort of asking for something too late.
>>
>> If you reference the "notThis" keyword inside a callback method that has
>> been separated from "its own" class instance, you're now saying "could you
>> please do this all in the context of your instance", but your method
>> doesn't know what its instance is because it never saved a reference.
>>
>> Alternatively the compiler would notice that the "notThis" keyword is
>> invoked inside a method, and automatically make a bound property on
>> construction. The problem is that you're eagerly making a copy of every
>> method using "notThis" for every instance that exists - eating up a whole
>> bunch of extra memory for large collections - without knowing necessarily
>> that those bound copies will be used. Granted, we're triggering the same
>> problem when folks are using "class property arrow methods" for all their
>> methods in React classes.
>>
>> Ben
>>
>> Le lun. 11 mars 2019 11 h 04, john larson  a
>> écrit :
>>
>>> *@Rob:* Thanks for pointing out "proposal-bind-operator". I examined
>>> the proposal and as far as I understand, it is just another way to create a
>>> bound enclosing function. What I am proposing is just the opposite, no
>>> binding should take place in the enclosing function. A method call or usage
>>> of a property should already have its lexical scope pointing to the class
>>> instance and should not need any binding of its enclosing environment to
>>> function correctly.
>>>
>>> On Mon, Mar 11, 2019 at 4:57 PM Rob Ede  wrote:
>>>
 I would imagine that this can be achieved with bind operator proposal,
 which already has Babel support, despite no examples showing usage inside a
 class.

 Something like:
 `oReq.addEventListener("load", ::this.responseHandler);`
 seems to be the syntax that will de-sugar to
 `oReq.addEventListener("load", this.responseHandler.bind(this));`
 to get you the desired this binding.

 I’m surprised this idea hasn't been mentioned yet although things have
 been moving slowly on that proposal and it seems to need some community
 support to move along.

 Regards,
 Rob


 References:
 1: Bind Syntax Proposal (https://github.com/tc39/proposal-bind-operator
 )
 2: Babel Plugin (
 https://babeljs.io/docs/en/next/babel-plugin-proposal-function-bind)

 ___
>>> 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: Proposal For A New Alternative Keyword To “this” For Classes

[john larson]

Well, actually this is the same discussion we had with *@Jordan Harband. *I
think the js run-time already has that information at hand, so as long as
we don't implement this as pure syntactical sugar, there would not be a
need to keep an extra reference to anything, because it would be already
there. The run-time will know which instance the invoked method belongs to.
But as I said, it would be insightful to get a js engine expert opinion on
this. Having said that, I believe it is just an implementation detail and
can be handled one way or the other. I guess the “class property arrow
methods in React" example you just provided also supports this notion.

On Mon, Mar 11, 2019 at 6:23 PM Ben Wiley  wrote:

> The main issue here is that you're sort of asking for something too late.
>
> If you reference the "notThis" keyword inside a callback method that has
> been separated from "its own" class instance, you're now saying "could you
> please do this all in the context of your instance", but your method
> doesn't know what its instance is because it never saved a reference.
>
> Alternatively the compiler would notice that the "notThis" keyword is
> invoked inside a method, and automatically make a bound property on
> construction. The problem is that you're eagerly making a copy of every
> method using "notThis" for every instance that exists - eating up a whole
> bunch of extra memory for large collections - without knowing necessarily
> that those bound copies will be used. Granted, we're triggering the same
> problem when folks are using "class property arrow methods" for all their
> methods in React classes.
>
> Ben
>
> Le lun. 11 mars 2019 11 h 04, john larson  a
> écrit :
>
>> *@Rob:* Thanks for pointing out "proposal-bind-operator". I examined the
>> proposal and as far as I understand, it is just another way to create a
>> bound enclosing function. What I am proposing is just the opposite, no
>> binding should take place in the enclosing function. A method call or usage
>> of a property should already have its lexical scope pointing to the class
>> instance and should not need any binding of its enclosing environment to
>> function correctly.
>>
>> On Mon, Mar 11, 2019 at 4:57 PM Rob Ede  wrote:
>>
>>> I would imagine that this can be achieved with bind operator proposal,
>>> which already has Babel support, despite no examples showing usage inside a
>>> class.
>>>
>>> Something like:
>>> `oReq.addEventListener("load", ::this.responseHandler);`
>>> seems to be the syntax that will de-sugar to
>>> `oReq.addEventListener("load", this.responseHandler.bind(this));`
>>> to get you the desired this binding.
>>>
>>> I’m surprised this idea hasn't been mentioned yet although things have
>>> been moving slowly on that proposal and it seems to need some community
>>> support to move along.
>>>
>>> Regards,
>>> Rob
>>>
>>>
>>> References:
>>> 1: Bind Syntax Proposal (https://github.com/tc39/proposal-bind-operator)
>>> 2: Babel Plugin (
>>> https://babeljs.io/docs/en/next/babel-plugin-proposal-function-bind)
>>>
>>> ___
>> 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: Proposal For A New Alternative Keyword To “this” For Classes

[Ben Wiley]

The main issue here is that you're sort of asking for something too late.

If you reference the "notThis" keyword inside a callback method that has
been separated from "its own" class instance, you're now saying "could you
please do this all in the context of your instance", but your method
doesn't know what its instance is because it never saved a reference.

Alternatively the compiler would notice that the "notThis" keyword is
invoked inside a method, and automatically make a bound property on
construction. The problem is that you're eagerly making a copy of every
method using "notThis" for every instance that exists - eating up a whole
bunch of extra memory for large collections - without knowing necessarily
that those bound copies will be used. Granted, we're triggering the same
problem when folks are using "class property arrow methods" for all their
methods in React classes.

Ben

Le lun. 11 mars 2019 11 h 04, john larson  a
écrit :

> *@Rob:* Thanks for pointing out "proposal-bind-operator". I examined the
> proposal and as far as I understand, it is just another way to create a
> bound enclosing function. What I am proposing is just the opposite, no
> binding should take place in the enclosing function. A method call or usage
> of a property should already have its lexical scope pointing to the class
> instance and should not need any binding of its enclosing environment to
> function correctly.
>
> On Mon, Mar 11, 2019 at 4:57 PM Rob Ede  wrote:
>
>> I would imagine that this can be achieved with bind operator proposal,
>> which already has Babel support, despite no examples showing usage inside a
>> class.
>>
>> Something like:
>> `oReq.addEventListener("load", ::this.responseHandler);`
>> seems to be the syntax that will de-sugar to
>> `oReq.addEventListener("load", this.responseHandler.bind(this));`
>> to get you the desired this binding.
>>
>> I’m surprised this idea hasn't been mentioned yet although things have
>> been moving slowly on that proposal and it seems to need some community
>> support to move along.
>>
>> Regards,
>> Rob
>>
>>
>> References:
>> 1: Bind Syntax Proposal (https://github.com/tc39/proposal-bind-operator)
>> 2: Babel Plugin (
>> https://babeljs.io/docs/en/next/babel-plugin-proposal-function-bind)
>>
>> ___
> 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: Proposal For A New Alternative Keyword To “this” For Classes

[john larson]

*@Rob:* Thanks for pointing out "proposal-bind-operator". I examined the
proposal and as far as I understand, it is just another way to create a
bound enclosing function. What I am proposing is just the opposite, no
binding should take place in the enclosing function. A method call or usage
of a property should already have its lexical scope pointing to the class
instance and should not need any binding of its enclosing environment to
function correctly.

On Mon, Mar 11, 2019 at 4:57 PM Rob Ede  wrote:

> I would imagine that this can be achieved with bind operator proposal,
> which already has Babel support, despite no examples showing usage inside a
> class.
>
> Something like:
> `oReq.addEventListener("load", ::this.responseHandler);`
> seems to be the syntax that will de-sugar to
> `oReq.addEventListener("load", this.responseHandler.bind(this));`
> to get you the desired this binding.
>
> I’m surprised this idea hasn't been mentioned yet although things have
> been moving slowly on that proposal and it seems to need some community
> support to move along.
>
> Regards,
> Rob
>
>
> References:
> 1: Bind Syntax Proposal (https://github.com/tc39/proposal-bind-operator)
> 2: Babel Plugin (
> https://babeljs.io/docs/en/next/babel-plugin-proposal-function-bind)
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal For A New Alternative Keyword To “this” For Classes

[Rob Ede]

I would imagine that this can be achieved with bind operator proposal, which 
already has Babel support, despite no examples showing usage inside a class.

Something like:
`oReq.addEventListener("load", ::this.responseHandler);`
seems to be the syntax that will de-sugar to
`oReq.addEventListener("load", this.responseHandler.bind(this));`
to get you the desired this binding.

I’m surprised this idea hasn't been mentioned yet although things have been 
moving slowly on that proposal and it seems to need some community support to 
move along.

Regards,
Rob


References:
1: Bind Syntax Proposal (https://github.com/tc39/proposal-bind-operator 
)
2: Babel Plugin 
(https://babeljs.io/docs/en/next/babel-plugin-proposal-function-bind 
)

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

Re: Proposal For A New Alternative Keyword To “this” For Classes

[john larson]

First of all, thank you all for taking the time to review the proposal and
sharing your valuable opinions. I would like to note that the proposal aims
not to add a new capability that was not possible to do before but rather
move the standard forward on the way for a modern, better and easier to use
language for all the developers. Advancements of the language, or any
language in that matter, throughout the last decade also followed a similar
path because we were already able to do everything in one way or the other.
We actually strive for the same thing, a better Javascript.



That being said, let me try to clarify my proposal further by walking you
through my thought process:



Normally if I try to write a class similar to the sample code I have given
in my first email using an object oriented programming language like Java,
C# etc., I would be writing something similar to the following:



class RequestManager

{

string successMessage = "Xhr successful.";



void makeRequest()

{

var oReq = new XMLHttpRequest();

oReq.addEventListener("load", responseHandler);

oReq.open("GET", "*www.google.com* <#inbox/_blank>");

oReq.send();

}



void responseHandler()

{

window.alert(successMessage);

}

}



As you can see, I do not even have to use a special keyword for referring
to methods from inside the class. Because they are already in lexical
scope. Now, if this can be accomplished in Javascript without hitting some
limitation/restriction due to the current state of the language, I think it
would be the ideal solution. (This limitation might be the class syntax
being just a syntactical sugar or some other reason that I cannot foresee
right now and that would require a breaking change.) And I would happily
change the proposal that way: “A no-keyword alternative for the “this””. If
I should summarize this approach, I can say that every method of the class
is going to assume the behavior we now have with arrow functions, but
without requiring the use of the “this” and the arrow function syntax.



As contrary to the ideal solution, the last thing I would want would be to
use a context-dependant keyword like the “this” to refer to
methods/properties of the object and then try to set the context right by
using binding or arrow functions. This referral should be lexical, not
context-dependant. If I have the intent of referring to the instance
method/property, that intent should manifest itself right there where I am
using this method/property. I shouldn’t be looking at if this takes place
inside an arrow function, or if the enclosing method is called with a
binding or not. Why should I care about the enclosing of the call, right?

By the way, MDN also mentions the following about the use of arrow functions:
“Arrow function expressions are ill suited as methods”.

*@Yulia:* Thanks for pointing out the decorator approach. But that also
seems to deal with the enclosing and tries to solve the problem with a
“context binding” approach. The only difference is the way it determines
the binding. I am against this binding approach all together. Only the
lexical scope of the code should be taken into consideration.



So far, I have laid out what I think the ideal solution is and what I think
the problematic state we are in right now. And as a middle-ground, in case
the ideal solution cannot be applied, I proposed a new keyword to use
instead of the “this” so that it will always refer to the instance,
regardless of execution context binding. In which case, when you replace
the “this” in the problematic sample code in my initial email, it will work
just fine. Let’ assume for the sake of this example that the new keyword is
“self”:



class RequestManager{



constructor(){

*self*.successMessage = "Xhr successful.";

}





makeRequest() {

var oReq = new XMLHttpRequest();

oReq.addEventListener("load", *self*.responseHandler);

oReq.open("GET", "*www.google.com* <#inbox/_blank>");

oReq.send();

}



responseHandler() {

window.alert(*self*.successMessage);

}

}



var reqManager = new RequestManager();

reqManager.makeRequest();



As you can see, self.responseHandler will always point to the
responseHandler method no matter whether the enclosing is a method, an
arrow function or if it is called using a bind syntax or not.

I would be happy to further address your concerns about this explanation if
you have any.



On Sun, Mar 10, 2019 at 10:30 PM guest271314  wrote:

> This is probably not the pattern that is being proposed though outputs the
> expected result
>
> ```class RequestManager {
>   constructor() {
> this.successMessage = "Xhr successful.";
> RequestManager.

Re: Proposal For A New Alternative Keyword To “this” For Classes

[guest271314]

This is probably not the pattern that is being proposed though outputs the
expected result

```class RequestManager {
  constructor() {
this.successMessage = "Xhr successful.";
RequestManager.THIS = this;
  }

  makeRequest() {
var oReq = new XMLHttpRequest();
oReq.addEventListener("load", this.responseHandler);
oReq.open("GET", "");
oReq.send();
  }

  responseHandler(e) {
console.log(e, this); // `e`: event, `this`: XMLHttpRequest instance
console.log(RequestManager.THIS.successMessage);
  }

}

var reqManager = new RequestManager();

reqManager.makeRequest();```

On Sat, Mar 9, 2019 at 11:42 AM john larson 
wrote:

> *Summary of the problem:*
>
> “this” keyword in Javascript is context dependent. And this is one of the
> culprits of most subtle and latent errors in Javascript. Moreover, use of
> “this” cannot be avoided if we are using classes and trying to reference
> instance properties.
>
> When “this” is used in callback functions or in functions given
> to forEach as argument, IDEs rightfully cannot raise any design-time
> errors, giving developers the false sense of security, but we get run-time
> errors because “this” is undefined.
>
> There seem to be two work-arounds:
>
> 1.  Using arrow functions
>
> 2.  Using .bind(this) syntax
>
> Just assuming we forgot to use an arrow function or a .bind(), the IDE
> will not be able to raise an error and we will encounter the error in
> run-time.
>
>
>
> *What I propose:*
>
> I am proposing a new keyword that will be the alternative of "this" and
> will always point to the instance of the class. The name of the new keyword
> can be chosen with consensus from the community such that it would
> minimize/eliminate collision in existing codebases.
>
>
>
> Here is a sample js code:
>
>
>
> class RequestManager{
>
>
>
> constructor(){
>
> this.successMessage = "Xhr successful.";
>
> }
>
>
>
>
>
> makeRequest() {
>
> var oReq = new XMLHttpRequest();
>
> oReq.addEventListener("load", this.responseHandler);
>
> oReq.open("GET", "www.google.com");
>
> oReq.send();
>
> }
>
>
>
> responseHandler() {
>
> window.alert(this.successMessage);
>
> }
>
> }
>
>
>
> var reqManager = new RequestManager();
>
> reqManager.makeRequest();
>
>
>
> This piece of code will alert “undefined” because “this” is undefined in
> the callback function in strict mode.
>
> Now let’s assume a new keyword is used insetead of “this” that will always
> point to the class instance.
>
> As per its implementation, as described on
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes:
>
> *“JavaScript classes, introduced in ECMAScript 2015, are primarily
> syntactical sugar over JavaScript's existing prototype-based inheritance.
> The class syntax does not introduce a new object-oriented inheritance model
> to JavaScript.”*
>
> So with the new keyword introduced, behind the scenes, previous class
> could be interpreted as a piece of code along the lines of:
>
>
>
> var RequestManager = function () {
>
> var self = this;
>
>     self.successMessage = "Xhr successful";
>
>
>
> self.makeRequest = function () {
>
> var oReq = new XMLHttpRequest();
>
> oReq.addEventListener("load", responseHandler);
>
> oReq.open("GET", "www.google.com");
>
> oReq.send();
>
> };
>
>
>
> var responseHandler = function () {
>
> window.alert(self.successMessage);
>
> };
>
> };
>
> var reqManager = new RequestManager();
>
>
>
> reqManager.makeRequest();
>
>
>
> I believe this way, we would not have to resort to work-arounds for such a
> fundamental construct of the language and this would ease developers’ lives
> as someone forgetting to have used an arrow function or the .bind(this)
> syntax will not be a problem anymore.
>
>
>
> Best Regards,
>
> John
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
>  Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
> <#m_-8001099771182452640_m_-1339185979708762546_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

Re: Proposal For A New Alternative Keyword To “this” For Classes

[Michał Wadas]

This is solvable with decorators or getters.

class Foo {

@cached
get method() {
return () => this.foobar();
}

}

class Bar {

@bound
method() {
   return this.foobar();
}

}

Definitions for decorators @bound and @cached are pretty trivial.

On Sat, Mar 9, 2019 at 12:42 PM john larson 
wrote:

> *Summary of the problem:*
>
> “this” keyword in Javascript is context dependent. And this is one of the
> culprits of most subtle and latent errors in Javascript. Moreover, use of
> “this” cannot be avoided if we are using classes and trying to reference
> instance properties.
>
> When “this” is used in callback functions or in functions given
> to forEach as argument, IDEs rightfully cannot raise any design-time
> errors, giving developers the false sense of security, but we get run-time
> errors because “this” is undefined.
>
> There seem to be two work-arounds:
>
> 1.  Using arrow functions
>
> 2.  Using .bind(this) syntax
>
> Just assuming we forgot to use an arrow function or a .bind(), the IDE
> will not be able to raise an error and we will encounter the error in
> run-time.
>
>
>
> *What I propose:*
>
> I am proposing a new keyword that will be the alternative of "this" and
> will always point to the instance of the class. The name of the new keyword
> can be chosen with consensus from the community such that it would
> minimize/eliminate collision in existing codebases.
>
>
>
> Here is a sample js code:
>
>
>
> class RequestManager{
>
>
>
>     constructor(){
>
> this.successMessage = "Xhr successful.";
>
> }
>
>
>
>
>
> makeRequest() {
>
> var oReq = new XMLHttpRequest();
>
> oReq.addEventListener("load", this.responseHandler);
>
> oReq.open("GET", "www.google.com");
>
> oReq.send();
>
> }
>
>
>
> responseHandler() {
>
> window.alert(this.successMessage);
>
> }
>
> }
>
>
>
> var reqManager = new RequestManager();
>
> reqManager.makeRequest();
>
>
>
> This piece of code will alert “undefined” because “this” is undefined in
> the callback function in strict mode.
>
> Now let’s assume a new keyword is used insetead of “this” that will always
> point to the class instance.
>
> As per its implementation, as described on
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes:
>
> *“JavaScript classes, introduced in ECMAScript 2015, are primarily
> syntactical sugar over JavaScript's existing prototype-based inheritance.
> The class syntax does not introduce a new object-oriented inheritance model
> to JavaScript.”*
>
> So with the new keyword introduced, behind the scenes, previous class
> could be interpreted as a piece of code along the lines of:
>
>
>
> var RequestManager = function () {
>
> var self = this;
>
> self.successMessage = "Xhr successful";
>
>
>
> self.makeRequest = function () {
>
> var oReq = new XMLHttpRequest();
>
> oReq.addEventListener("load", responseHandler);
>
> oReq.open("GET", "www.google.com");
>
> oReq.send();
>
> };
>
>
>
> var responseHandler = function () {
>
> window.alert(self.successMessage);
>
> };
>
> };
>
> var reqManager = new RequestManager();
>
>
>
> reqManager.makeRequest();
>
>
>
> I believe this way, we would not have to resort to work-arounds for such a
> fundamental construct of the language and this would ease developers’ lives
> as someone forgetting to have used an arrow function or the .bind(this)
> syntax will not be a problem anymore.
>
>
>
> Best Regards,
>
> John
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
>  Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
> <#m_-510229116124742616_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

Re: Re: Re: Proposal For A New Alternative Keyword To “this” For Classes

[Yulia Startsev]

I was asked by John to chime in, and I will repeat here what I sent to him
directly via email.

Thanks for making the proposal and thinking through this problem. Indeed,
`this` is a confusing concept for many people, and is an existing baggage
from early JavaScript Design.

This having been said, it isn't clear to me what you are proposing. Your
proposal is already possible in JavaScript as is, it is not adding a new
capability to the language, it is instead introducing syntax as a work
around that has already been extensively tooled. So, knowing this, how do
we approach this problem? People are definitely struggling with this issue,
so how can we do it better?

Let's play with this problem a bit. From your proposal it looks like you
want a way to clearly identify methods on a class to have access to the
`this` that is the class instance. At the moment, as you mention, you have
to bind it in the constructor. What if it was a list of "bound methods"? or
a keyword at the beginning of the class declaration called bound.

```
class Xyz {
  boundMethods = ["counter"];
   constructor() {
this.count = 0;
// something
  }

  counter() {
this.count++;
  }

  render() {
  // some code
  element.addEventListener("click", this.counter);
  }
}
```

Well, that looks a bit ugly, and I can imagine a class having a lot of
these and it not being much better than what we had before. Plus, it isn't
clear to a programmer what is going on here. Let's try something else

What if we had a keyword like `async`?

```

class Xyz {
  constructor() {
this.count = 0;
// something
  }

  bound counter() {
this.count++;
  }

  render() {
  // some code
  element.addEventListener("click", this.counter);
  }
}

```

You get the idea. So this is another way to think about the problem. But if
we do this, then suddenly, we are going to be adding a huge list of
keywords to the beginning! imaging `bound async nameOfFunction()`, and also
how do you know what order they should be in?. So maybe there is another
solution? Maybe someone has tried something before.

If we go through the current proposals that are in flight at the TC39,
there is a proposal that also tries to tackle this, the decorators
proposal. Take a look at how decorators solves the same problem:
https://github.com/tc39/proposal-decorators#decorators

here is how it is done there (simplified, only showing `@bound` at work):

```

class Counter extends HTMLElement {
  _x = 0;

  @bound
  _clicked() {
this._x++;
  }

  constructor() {
super();
this.onClick = this._clicked; // this is a private method, see the
proposal for more details
  }

  connectedCallback() { this.render(); }

  render() {

// ... it does something, lets imagine creates an element that
listens for a click

element.addEventListener("click", this.onClick)

  }
}

```

I removed some of the complexity of the original example, to help make it
clear what is going on here in relation to what you were suggesting. The
way it works is @bound makes clicked into an auto-bound method, replacing
the explicit bind call later. You can read more about this in the proposal
I linked. This is one way to address the issue that you bring up, without
introducing a new keyword `self`.

It might be worth looking through some previous proposals to get a sense of
how others have tried to tackle the problem. For the decorators proposal,
it is really just a starting point -- you might find other points of
reference. See if it is what you were looking for. If it doesn't fully
address the case, it might point you in a direction that gets closer to a
proposal, or it might bring up other interesting questions. We don't have
to start with a fully formed solution -- collecting problems and
constraints is an interesting way to work.

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

Re: Proposal For A New Alternative Keyword To “this” For Classes

[Jordan Harband]

There'd still have to be a way for an arbitrary function - which (unless
called in `a.b()` form) has no guaranteed connection back to `a` - to have
a reference back to the object.

On Sat, Mar 9, 2019 at 10:57 PM Michael Luder-Rosefield <
rosyatran...@gmail.com> wrote:

> How about binding `this` to a variable in the constructor? The following
> syntax throws an error due to `this` being a reserved word, so won't break
> any existing code:
>
> ```
> class Foo {
>   constructor (this: self, /* normal args */) {
> // ...
>   }
> }
> ```
>
> I can see arguments against that as it breaks the convention for how
> parameter lists work, and also requires a constructor. Perhaps, then, we
> could either use something like a modified version of class field
> declarations to make class variables:
>
> ```
> class Foo {
>   const self = this;
>   // ...
> }
> ```
>
> Or, maybe, allow parentheses before the class body to define variables:
>
> ```
> class Foo (this: self) {
>   //...
> }
> ```
>
> No, I don't like that one either.
>
> The second suggestion (class variables as extension of class fields
> proposal) seems like it has potential to me, so it seems like an excellent
> time for everyone here to tell me why it's awful and stupid.
>
> On Sun, 10 Mar 2019 at 06:59 Jordan Harband  wrote:
>
>> The engine only has that knowledge when you call it in `a.b()` form - at
>> which point, `this` is already the instance. For a keyword to not be
>> context dependent, it'd have to be the instance even when you'd done
>> something like `const { b } = a; b()`. To do this would require either a)
>> `a` has its own distinct copy of `b` that's bound to `a`, or b) `a.b` to be
>> a getter that does that binding upon request.
>>
>> Constructor-binding, field-binding, or arrow function fields all work the
>> same way - they create a separate copy of a function for *each and every*
>> instance, so that the function can point back to the instance even when
>> extracted off of the object.
>>
>> I'm not clear on how there'd be any other way to do it.
>>
>> On Sat, Mar 9, 2019 at 1:41 PM john larson 
>> wrote:
>>
>>> Although the method lives on the prototype, the engine should already
>>> have knowledge of the object whose method is being invoked. I am not an
>>> expert on the internal workings of the engine, so I would be glad if anyone
>>> would correct me on this if I am wrong.
>>>
>>>
>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
>>>  Virus-free.
>>> www.avast.com
>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
>>> <#m_4773041203224270933_m_6849901573705770350_m_-8660865756228832385_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>
>>> On Sun, Mar 10, 2019 at 12:27 AM Jordan Harband 
>>> wrote:
>>>
>>>> An additional keyword like this would require a function to have a
>>>> hidden reference back to the instance. However, especially for `class`
>>>> methods, but also for ES5-style inheritance, or even for `class Foo {}
>>>> Foo.prototype.bar = function () {}`, methods are *shared*. You might have a
>>>> billion instances, but only one function that uses your new keyword - how
>>>> would the engine know which instance you were referring to?
>>>>
>>>> On Sat, Mar 9, 2019 at 7:50 AM Bergi  wrote:
>>>>
>>>>> Hi John,
>>>>>
>>>>> > I believe that it would be a trivial task for
>>>>> > current static code analyzers to restrict usage of "this" for anyone
>>>>> > opting in to use this new keyword exclusively.
>>>>>
>>>>> Static tooling, like the TypeScript compiler, can detect problematic
>>>>> method usage already today. Sure, having a dedicated syntax for this
>>>>> will make static analysis simpler, but I don't deem that a worthy
>>>>> addition to the language.
>>>>>
>>>>> > As you mentioned, arrow functions might have their own
>>>>> > problems. Wouldn't such an alternative keyword be a good addition to
>>>>> our
>>>>> > toolkit anyway?
>>>>>
>>>>> What I was trying to say is that your proposed alternative has exactly
>>>>> the same problems as instance-member arrow functions have today.
>>>>>
>>>>> Best regards,
>>>>>   Bergi
>>>>> ___
>>>>> 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: Proposal For A New Alternative Keyword To “this” For Classes

[Michael Luder-Rosefield]

How about binding `this` to a variable in the constructor? The following
syntax throws an error due to `this` being a reserved word, so won't break
any existing code:

```
class Foo {
  constructor (this: self, /* normal args */) {
// ...
  }
}
```

I can see arguments against that as it breaks the convention for how
parameter lists work, and also requires a constructor. Perhaps, then, we
could either use something like a modified version of class field
declarations to make class variables:

```
class Foo {
  const self = this;
  // ...
}
```

Or, maybe, allow parentheses before the class body to define variables:

```
class Foo (this: self) {
  //...
}
```

No, I don't like that one either.

The second suggestion (class variables as extension of class fields
proposal) seems like it has potential to me, so it seems like an excellent
time for everyone here to tell me why it's awful and stupid.

On Sun, 10 Mar 2019 at 06:59 Jordan Harband  wrote:

> The engine only has that knowledge when you call it in `a.b()` form - at
> which point, `this` is already the instance. For a keyword to not be
> context dependent, it'd have to be the instance even when you'd done
> something like `const { b } = a; b()`. To do this would require either a)
> `a` has its own distinct copy of `b` that's bound to `a`, or b) `a.b` to be
> a getter that does that binding upon request.
>
> Constructor-binding, field-binding, or arrow function fields all work the
> same way - they create a separate copy of a function for *each and every*
> instance, so that the function can point back to the instance even when
> extracted off of the object.
>
> I'm not clear on how there'd be any other way to do it.
>
> On Sat, Mar 9, 2019 at 1:41 PM john larson 
> wrote:
>
>> Although the method lives on the prototype, the engine should already
>> have knowledge of the object whose method is being invoked. I am not an
>> expert on the internal workings of the engine, so I would be glad if anyone
>> would correct me on this if I am wrong.
>>
>>
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
>>  Virus-free.
>> www.avast.com
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
>> <#m_6849901573705770350_m_-8660865756228832385_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> On Sun, Mar 10, 2019 at 12:27 AM Jordan Harband  wrote:
>>
>>> An additional keyword like this would require a function to have a
>>> hidden reference back to the instance. However, especially for `class`
>>> methods, but also for ES5-style inheritance, or even for `class Foo {}
>>> Foo.prototype.bar = function () {}`, methods are *shared*. You might have a
>>> billion instances, but only one function that uses your new keyword - how
>>> would the engine know which instance you were referring to?
>>>
>>> On Sat, Mar 9, 2019 at 7:50 AM Bergi  wrote:
>>>
>>>> Hi John,
>>>>
>>>> > I believe that it would be a trivial task for
>>>> > current static code analyzers to restrict usage of "this" for anyone
>>>> > opting in to use this new keyword exclusively.
>>>>
>>>> Static tooling, like the TypeScript compiler, can detect problematic
>>>> method usage already today. Sure, having a dedicated syntax for this
>>>> will make static analysis simpler, but I don't deem that a worthy
>>>> addition to the language.
>>>>
>>>> > As you mentioned, arrow functions might have their own
>>>> > problems. Wouldn't such an alternative keyword be a good addition to
>>>> our
>>>> > toolkit anyway?
>>>>
>>>> What I was trying to say is that your proposed alternative has exactly
>>>> the same problems as instance-member arrow functions have today.
>>>>
>>>> Best regards,
>>>>   Bergi
>>>> ___
>>>> 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: Proposal For A New Alternative Keyword To “this” For Classes

[Jordan Harband]

The engine only has that knowledge when you call it in `a.b()` form - at
which point, `this` is already the instance. For a keyword to not be
context dependent, it'd have to be the instance even when you'd done
something like `const { b } = a; b()`. To do this would require either a)
`a` has its own distinct copy of `b` that's bound to `a`, or b) `a.b` to be
a getter that does that binding upon request.

Constructor-binding, field-binding, or arrow function fields all work the
same way - they create a separate copy of a function for *each and every*
instance, so that the function can point back to the instance even when
extracted off of the object.

I'm not clear on how there'd be any other way to do it.

On Sat, Mar 9, 2019 at 1:41 PM john larson  wrote:

> Although the method lives on the prototype, the engine should already have
> knowledge of the object whose method is being invoked. I am not an expert
> on the internal workings of the engine, so I would be glad if anyone would
> correct me on this if I am wrong.
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
>  Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
> <#m_-8660865756228832385_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Sun, Mar 10, 2019 at 12:27 AM Jordan Harband  wrote:
>
>> An additional keyword like this would require a function to have a hidden
>> reference back to the instance. However, especially for `class` methods,
>> but also for ES5-style inheritance, or even for `class Foo {}
>> Foo.prototype.bar = function () {}`, methods are *shared*. You might have a
>> billion instances, but only one function that uses your new keyword - how
>> would the engine know which instance you were referring to?
>>
>> On Sat, Mar 9, 2019 at 7:50 AM Bergi  wrote:
>>
>>> Hi John,
>>>
>>> > I believe that it would be a trivial task for
>>> > current static code analyzers to restrict usage of "this" for anyone
>>> > opting in to use this new keyword exclusively.
>>>
>>> Static tooling, like the TypeScript compiler, can detect problematic
>>> method usage already today. Sure, having a dedicated syntax for this
>>> will make static analysis simpler, but I don't deem that a worthy
>>> addition to the language.
>>>
>>> > As you mentioned, arrow functions might have their own
>>> > problems. Wouldn't such an alternative keyword be a good addition to
>>> our
>>> > toolkit anyway?
>>>
>>> What I was trying to say is that your proposed alternative has exactly
>>> the same problems as instance-member arrow functions have today.
>>>
>>> Best regards,
>>>   Bergi
>>> ___
>>> 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: Proposal For A New Alternative Keyword To “this” For Classes

[john larson]

Although the method lives on the prototype, the engine should already have
knowledge of the object whose method is being invoked. I am not an expert
on the internal workings of the engine, so I would be glad if anyone would
correct me on this if I am wrong.

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sun, Mar 10, 2019 at 12:27 AM Jordan Harband  wrote:

> An additional keyword like this would require a function to have a hidden
> reference back to the instance. However, especially for `class` methods,
> but also for ES5-style inheritance, or even for `class Foo {}
> Foo.prototype.bar = function () {}`, methods are *shared*. You might have a
> billion instances, but only one function that uses your new keyword - how
> would the engine know which instance you were referring to?
>
> On Sat, Mar 9, 2019 at 7:50 AM Bergi  wrote:
>
>> Hi John,
>>
>> > I believe that it would be a trivial task for
>> > current static code analyzers to restrict usage of "this" for anyone
>> > opting in to use this new keyword exclusively.
>>
>> Static tooling, like the TypeScript compiler, can detect problematic
>> method usage already today. Sure, having a dedicated syntax for this
>> will make static analysis simpler, but I don't deem that a worthy
>> addition to the language.
>>
>> > As you mentioned, arrow functions might have their own
>> > problems. Wouldn't such an alternative keyword be a good addition to our
>> > toolkit anyway?
>>
>> What I was trying to say is that your proposed alternative has exactly
>> the same problems as instance-member arrow functions have today.
>>
>> Best regards,
>>   Bergi
>> ___
>> 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: Proposal For A New Alternative Keyword To “this” For Classes

[Jordan Harband]

An additional keyword like this would require a function to have a hidden
reference back to the instance. However, especially for `class` methods,
but also for ES5-style inheritance, or even for `class Foo {}
Foo.prototype.bar = function () {}`, methods are *shared*. You might have a
billion instances, but only one function that uses your new keyword - how
would the engine know which instance you were referring to?

On Sat, Mar 9, 2019 at 7:50 AM Bergi  wrote:

> Hi John,
>
> > I believe that it would be a trivial task for
> > current static code analyzers to restrict usage of "this" for anyone
> > opting in to use this new keyword exclusively.
>
> Static tooling, like the TypeScript compiler, can detect problematic
> method usage already today. Sure, having a dedicated syntax for this
> will make static analysis simpler, but I don't deem that a worthy
> addition to the language.
>
> > As you mentioned, arrow functions might have their own
> > problems. Wouldn't such an alternative keyword be a good addition to our
> > toolkit anyway?
>
> What I was trying to say is that your proposed alternative has exactly
> the same problems as instance-member arrow functions have today.
>
> Best regards,
>   Bergi
> ___
> 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: Proposal For A New Alternative Keyword To “this” For Classes

[Bergi]

Hi John,


I believe that it would be a trivial task for
current static code analyzers to restrict usage of "this" for anyone
opting in to use this new keyword exclusively.


Static tooling, like the TypeScript compiler, can detect problematic
method usage already today. Sure, having a dedicated syntax for this
will make static analysis simpler, but I don't deem that a worthy
addition to the language.


As you mentioned, arrow functions might have their own
problems. Wouldn't such an alternative keyword be a good addition to our
toolkit anyway?


What I was trying to say is that your proposed alternative has exactly
the same problems as instance-member arrow functions have today.

Best regards,
 Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal For A New Alternative Keyword To “this” For Classes

[john larson]

Hi Bergi,

Thanks for your input. I believe that it would be a trivial task for
current static code analyzers to restrict usage of "this" for anyone opting
in to use this new keyword exclusively. But the same does not hold true for
other work-arounds such as arrow functions. And in addition to that, as you
mentioned, arrow functions might have their own problems. Wouldn't such an
alternative keyword be a good addition to our toolkit anyway?

Best Regards,
John

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sat, Mar 9, 2019 at 5:18 PM Bergi  wrote:

> Hi John,
> I don't think we do need another keyword for this. People would forget
> to use that new keyword instead of using this, just like they currently
> forget to use arrow functions.
> That said, your desired "behind-the-scenes implementation" can already
> be achieved easily with the class fields proposal and an arrow function.
> However, [there are many problems with that
> approach](
> https://medium.com/@charpeni/arrow-functions-in-class-properties-might-not-be-as-great-as-we-think-3b3551c440b1
> )
> anyway.
>
> kind regards,
>   Bergi
> ___
> 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: Proposal For A New Alternative Keyword To “this” For Classes

[Bergi]

Hi John,
I don't think we do need another keyword for this. People would forget
to use that new keyword instead of using this, just like they currently
forget to use arrow functions.
That said, your desired "behind-the-scenes implementation" can already
be achieved easily with the class fields proposal and an arrow function.
However, [there are many problems with that
approach](https://medium.com/@charpeni/arrow-functions-in-class-properties-might-not-be-as-great-as-we-think-3b3551c440b1)
anyway.

kind regards,
 Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Proposal For A New Alternative Keyword To “this” For Classes

[john larson]

*Summary of the problem:*

“this” keyword in Javascript is context dependent. And this is one of the
culprits of most subtle and latent errors in Javascript. Moreover, use of
“this” cannot be avoided if we are using classes and trying to reference
instance properties.

When “this” is used in callback functions or in functions given
to forEach as argument, IDEs rightfully cannot raise any design-time
errors, giving developers the false sense of security, but we get run-time
errors because “this” is undefined.

There seem to be two work-arounds:

1.  Using arrow functions

2.  Using .bind(this) syntax

Just assuming we forgot to use an arrow function or a .bind(), the IDE will
not be able to raise an error and we will encounter the error in run-time.



*What I propose:*

I am proposing a new keyword that will be the alternative of "this" and
will always point to the instance of the class. The name of the new keyword
can be chosen with consensus from the community such that it would
minimize/eliminate collision in existing codebases.



Here is a sample js code:



class RequestManager{



constructor(){

this.successMessage = "Xhr successful.";

}





makeRequest() {

    var oReq = new XMLHttpRequest();

oReq.addEventListener("load", this.responseHandler);

oReq.open("GET", "www.google.com");

oReq.send();

}



responseHandler() {

window.alert(this.successMessage);

}

}



var reqManager = new RequestManager();

reqManager.makeRequest();



This piece of code will alert “undefined” because “this” is undefined in
the callback function in strict mode.

Now let’s assume a new keyword is used insetead of “this” that will always
point to the class instance.

As per its implementation, as described on
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes:

*“JavaScript classes, introduced in ECMAScript 2015, are primarily
syntactical sugar over JavaScript's existing prototype-based inheritance.
The class syntax does not introduce a new object-oriented inheritance model
to JavaScript.”*

So with the new keyword introduced, behind the scenes, previous class could
be interpreted as a piece of code along the lines of:



var RequestManager = function () {

var self = this;

self.successMessage = "Xhr successful";



self.makeRequest = function () {

var oReq = new XMLHttpRequest();

oReq.addEventListener("load", responseHandler);

oReq.open("GET", "www.google.com");

oReq.send();

};



var responseHandler = function () {

window.alert(self.successMessage);

};

};

var reqManager = new RequestManager();



reqManager.makeRequest();



I believe this way, we would not have to resort to work-arounds for such a
fundamental construct of the language and this would ease developers’ lives
as someone forgetting to have used an arrow function or the .bind(this)
syntax will not be a problem anymore.



Best Regards,

John

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: New Proposal: Number.range (Yes, range again)

[Cyril Auburtin]

I'm really cheering for the slice-notation range extension proposed in
https://github.com/tc39/proposal-slice-notation/issues/19#issuecomment-421453934

```js
for (const i of Number.range(0, 43)) {
console.log(i) // 0 to 42
}

const fakeData = [...Number.range(1, 21)].map(x => x ** 2)
```
becomes
```js
for (const i of (0:43)) {
console.log(i) // 0 to 42
}

const fakeData = [...(1:21)].map(x => x ** 2)
```


On Fri, Jan 18, 2019 at 3:41 PM Jack Works  wrote:

> Hello everyone, I made a formal proposal
> https://github.com/Jack-Works/proposal-Number.range , welcome to disscuss
> the details in the repo!
>
> On Thu, Nov 29, 2018 at 3:01 PM Jordan Harband  wrote:
>
>> It's not a "standard library" unless every part of it has gone through a
>> full standards process.
>>
>> On Wed, Nov 28, 2018 at 8:31 PM Jacob Pratt  wrote:
>>
>>> I'm not saying we should add it on to that proposal, but rather saying
>>> that I think more effort should be put into a standard library where things
>>> like this don't need to go through a full standards process. That's just my
>>> opinion, and borderline on-topic for this specific suggestion.
>>>
>>> I'm absolutely in favor of having a `range` method, it's just _where_ it
>>> should be that I differ.
>>>
>>> Jacob Pratt
>>>
>>> On Thu, Nov 29, 2018 at 4:29 AM Jack Works  wrote:
>>>
>>>> Oh, I'm not here to find out how to implement a range in detail. That's
>>>> the trivial things, I want to first make it become a stage 0 proposal, then
>>>> we can discuss if we need some overload or how to deal with the edge cases.
>>>> Ps, does Pratt mean we should add it as a standard library in the stage
>>>> 1 standard libraray proposal?
>>>>
>>>> On Thu, Nov 29, 2018, 12:18 Jacob Pratt  wrote:
>>>>
>>>>> Quick, simple TypeScript range function (with overloads, of course).
>>>>>
>>>>> ```
>>>>> export function range(end: number): IterableIterator;
>>>>> export function range(start: number, end: number):
>>>>> IterableIterator;
>>>>> export function range(start: number, end: number, step: number):
>>>>> IterableIterator;
>>>>> export function* range(start: number, end?: number, step?: number):
>>>>> IterableIterator {
>>>>>   // overload #1
>>>>>   if (end === undefined) {
>>>>> [start, end, step] = [0, start, 1];
>>>>>   }
>>>>>
>>>>>   // overload #2
>>>>>   if (step === undefined) {
>>>>> step = Math.sign(end - start);
>>>>>   }
>>>>>
>>>>>   // ensure we have the appropriate types
>>>>>   if (typeof start !== 'number' || typeof end !== 'number' || typeof
>>>>> step !== 'number') {
>>>>> throw new TypeError('all parameters must be of type number');
>>>>>   }
>>>>>
>>>>>   while ((start < end && step > 0) || (start > end && step < 0)) {
>>>>> yield start;
>>>>> start += step;
>>>>>   }
>>>>> }
>>>>> ```
>>>>>
>>>>> IMO, we should focus on building up a JavaScript standard library that
>>>>> has tons of useful utilities like this, rather than continue to add 
>>>>> methods
>>>>> onto namespaces. Perhaps that's just me, though.
>>>>>
>>>>> Jacob Pratt
>>>>>
>>>>> On Wed, Nov 28, 2018 at 9:33 PM Tab Atkins Jr. 
>>>>> wrote:
>>>>>
>>>>>> I end up writing a range function in virtually every project I use, so
>>>>>> yeah, I think this is worthwhile.
>>>>>>
>>>>>> My own preferences, based on Python precedence:
>>>>>>
>>>>>> Number.range(end) === Number.range(0, end, 1)
>>>>>> Number.range(start, end) === Number.range(start, end,
>>>>>> Math.sign(end-start))
>>>>>> Number.range(start, end, step) => {
>>>>>>   if start < end && step > 0: yield all (start + k*step), for k from 0
>>>>>> to infinity, less than end
>>>>>>   elif start > end && step < 0: yield all (start + k*step), for k from
>>>>>> 0 to infinity, greater than end
>>>>>>   else: yield nothing
>>>>>> }
>>>>>>
>>>>>> So:
>>>>>> * [...Number.range(5)] evaluates to [0, 1, 2, 3, 4]
>>>>>> * [...Number.range(0)] evaluates to []
>>>>>> * [...Number.range(-5)] evaluates to []
>>>>>> * [...Number.range(1, -3)] evaluates to [1, 0, -1, -2]
>>>>>> * [...Number.range(-3, 1)] evaluates to [-3, -2, -1, 0]
>>>>>> * [...Number.range(1, 1)] evaluates to []
>>>>>> * [...Number.range(0, 10, 5)] evaluates to [0, 5]
>>>>>> * [...Number.range(0, 10, -5)] evaluates to []
>>>>>>
>>>>>> ~TJ
>>>>>>
>>>>> ___
>>>>>> 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: New Proposal: Number.range (Yes, range again)

[Jack Works]

Hello everyone, I made a formal proposal
https://github.com/Jack-Works/proposal-Number.range , welcome to disscuss
the details in the repo!

On Thu, Nov 29, 2018 at 3:01 PM Jordan Harband  wrote:

> It's not a "standard library" unless every part of it has gone through a
> full standards process.
>
> On Wed, Nov 28, 2018 at 8:31 PM Jacob Pratt  wrote:
>
>> I'm not saying we should add it on to that proposal, but rather saying
>> that I think more effort should be put into a standard library where things
>> like this don't need to go through a full standards process. That's just my
>> opinion, and borderline on-topic for this specific suggestion.
>>
>> I'm absolutely in favor of having a `range` method, it's just _where_ it
>> should be that I differ.
>>
>> Jacob Pratt
>>
>> On Thu, Nov 29, 2018 at 4:29 AM Jack Works  wrote:
>>
>>> Oh, I'm not here to find out how to implement a range in detail. That's
>>> the trivial things, I want to first make it become a stage 0 proposal, then
>>> we can discuss if we need some overload or how to deal with the edge cases.
>>> Ps, does Pratt mean we should add it as a standard library in the stage
>>> 1 standard libraray proposal?
>>>
>>> On Thu, Nov 29, 2018, 12:18 Jacob Pratt  wrote:
>>>
>>>> Quick, simple TypeScript range function (with overloads, of course).
>>>>
>>>> ```
>>>> export function range(end: number): IterableIterator;
>>>> export function range(start: number, end: number):
>>>> IterableIterator;
>>>> export function range(start: number, end: number, step: number):
>>>> IterableIterator;
>>>> export function* range(start: number, end?: number, step?: number):
>>>> IterableIterator {
>>>>   // overload #1
>>>>   if (end === undefined) {
>>>> [start, end, step] = [0, start, 1];
>>>>   }
>>>>
>>>>   // overload #2
>>>>   if (step === undefined) {
>>>> step = Math.sign(end - start);
>>>>   }
>>>>
>>>>   // ensure we have the appropriate types
>>>>   if (typeof start !== 'number' || typeof end !== 'number' || typeof
>>>> step !== 'number') {
>>>> throw new TypeError('all parameters must be of type number');
>>>>   }
>>>>
>>>>   while ((start < end && step > 0) || (start > end && step < 0)) {
>>>> yield start;
>>>> start += step;
>>>>   }
>>>> }
>>>> ```
>>>>
>>>> IMO, we should focus on building up a JavaScript standard library that
>>>> has tons of useful utilities like this, rather than continue to add methods
>>>> onto namespaces. Perhaps that's just me, though.
>>>>
>>>> Jacob Pratt
>>>>
>>>> On Wed, Nov 28, 2018 at 9:33 PM Tab Atkins Jr. 
>>>> wrote:
>>>>
>>>>> I end up writing a range function in virtually every project I use, so
>>>>> yeah, I think this is worthwhile.
>>>>>
>>>>> My own preferences, based on Python precedence:
>>>>>
>>>>> Number.range(end) === Number.range(0, end, 1)
>>>>> Number.range(start, end) === Number.range(start, end,
>>>>> Math.sign(end-start))
>>>>> Number.range(start, end, step) => {
>>>>>   if start < end && step > 0: yield all (start + k*step), for k from 0
>>>>> to infinity, less than end
>>>>>   elif start > end && step < 0: yield all (start + k*step), for k from
>>>>> 0 to infinity, greater than end
>>>>>   else: yield nothing
>>>>> }
>>>>>
>>>>> So:
>>>>> * [...Number.range(5)] evaluates to [0, 1, 2, 3, 4]
>>>>> * [...Number.range(0)] evaluates to []
>>>>> * [...Number.range(-5)] evaluates to []
>>>>> * [...Number.range(1, -3)] evaluates to [1, 0, -1, -2]
>>>>> * [...Number.range(-3, 1)] evaluates to [-3, -2, -1, 0]
>>>>> * [...Number.range(1, 1)] evaluates to []
>>>>> * [...Number.range(0, 10, 5)] evaluates to [0, 5]
>>>>> * [...Number.range(0, 10, -5)] evaluates to []
>>>>>
>>>>> ~TJ
>>>>>
>>>> ___
>>>>> 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: New Proposal: ES Call Stack

[Ranando King]

Isiah, that works when you're in full control of all the code. However,
when you're writing B, and A is 3rd party (or the reverse in DI cases) then
the API is out of your control. In cases like that, it's better if the data
itself knew the restrictions. That keeps dependencies low.

On Mon, Jan 14, 2019 at 3:57 PM Ranando King  wrote:

> We agree trying to learn about the caller should not affect how the caller
> works. That's why I was thinking more on the lines of an "id" carried
> around by every function object. As long as that "id" uniquely identified
> the function without providing any access to the function itself, it would
> satisfy my needs as well as TC39 and engine builder constraints.
>
> On Mon, Jan 14, 2019 at 1:31 AM Isiah Meadows 
> wrote:
>
>> You could substitute a function parameter accepting an object here or a
>> class instance for globals to dodge this. Doesn't change my point.
>>
>> Here's how you deal with permissions like that: have A know what data B
>> is allowed to access, then pass B an object with only that data. If
>> necessary, make the exposed methods form a closure over the relevant
>> private data.
>>
>> On Mon, Jan 14, 2019 at 00:50 Ranando King  wrote:
>>
>>> That's all fine and dandy until you're dealing with a project that has a
>>> "no globals" mandate. The problem that I'd want to be able to solve is one
>>> of gaining and losing control during a single function's execution.
>>> For example: say function A is privileged, but function B is not. Function
>>> A calls function B with some data that B should only partially be able to
>>> access. Right now, that's hardly possible. There's no way for the data
>>> being passed to know if it is ok for B to use those functions or
>>> properties. If it was possible for the data methods to peek at the stack
>>> and recognize that the current function isn't privileged, then the problem
>>> is solved.
>>>
>>> I know class-fields will make this a little easier, but it doesn't
>>> solve the problem, especially when there's a "no constructors" mandate.
>>>
>>> On Sun, Jan 13, 2019 at 9:08 PM Isiah Meadows 
>>> wrote:
>>>
 As for security, scope control is usually the more important thing to
 monitor. That's covered in realms for the most part, but also a few other
 things. Stack traces don't play a major part here, and whenever untrusted
 calls need made and tracked through the stack, it's not that hard to just
 save and restore global data as needed.
 On Sun, Jan 13, 2019 at 22:05 Isiah Meadows 
 wrote:

> You may be interested in this:
> https://github.com/tc39/proposal-error-stacks
> On Sun, Jan 13, 2019 at 22:02 Ranando King  wrote:
>
>> ES used to have Function.caller for traversing the call stack, but
>> apparently this was very problematic for engine development and prevented
>> various optimizations. So now it doesn't work in strict mode which makes 
>> it
>> useless for code involving `"use strict"` or `class`. One of the main use
>> cases for such functionality was being able to determine where a given
>> function was called from.
>>
>> I was thinking of a global static class that is able to uniquely
>> identify each execution context on the call stack without giving any 
>> access
>> to the context objects themselves. I was thinking of maybe something like
>> this:
>>
>> ```js
>> class CallStackEntry {
>>   #className;//Name of the class or null
>>   #functionName; //Name of the function or null
>>   #fileName; //Name of the source file or null
>>   #line; //Source line number
>>   #offset;   //Source character offset on the line
>>   #id;   //Symbol
>>   get fileName() { return this.#filename; }
>>   get line() { return this.#line; }
>>   get offset() { return this.#offset; }
>>   get id() { return this.#id; }
>>   constructor(_fileName, _line_, _offset, _id) {
>> this.#fileName = _fileName;
>> this.#line = _line;
>> this.#offset = _offset;
>> this.#id = _id;
>>   }
>> }
>>
>> class CallStack {
>>   static #callStack = []; //Internally managed
>>   static get stackLimit() {...}
>>   static set stackLimit(v) {...}
>>   static get stack() {
>> //return the call stack as an array of CallStackEntry objects
>>   }
>> }
>> ```
>>
>> With something like this, security-type software would be able to
>> clearly identify functions without granting any access rights to the
>> corresponding 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: New Proposal: ES Call Stack

[Ranando King]

We agree trying to learn about the caller should not affect how the caller
works. That's why I was thinking more on the lines of an "id" carried
around by every function object. As long as that "id" uniquely identified
the function without providing any access to the function itself, it would
satisfy my needs as well as TC39 and engine builder constraints.

On Mon, Jan 14, 2019 at 1:31 AM Isiah Meadows 
wrote:

> You could substitute a function parameter accepting an object here or a
> class instance for globals to dodge this. Doesn't change my point.
>
> Here's how you deal with permissions like that: have A know what data B is
> allowed to access, then pass B an object with only that data. If necessary,
> make the exposed methods form a closure over the relevant private data.
>
> On Mon, Jan 14, 2019 at 00:50 Ranando King  wrote:
>
>> That's all fine and dandy until you're dealing with a project that has a
>> "no globals" mandate. The problem that I'd want to be able to solve is one
>> of gaining and losing control during a single function's execution.
>> For example: say function A is privileged, but function B is not. Function
>> A calls function B with some data that B should only partially be able to
>> access. Right now, that's hardly possible. There's no way for the data
>> being passed to know if it is ok for B to use those functions or
>> properties. If it was possible for the data methods to peek at the stack
>> and recognize that the current function isn't privileged, then the problem
>> is solved.
>>
>> I know class-fields will make this a little easier, but it doesn't
>> solve the problem, especially when there's a "no constructors" mandate.
>>
>> On Sun, Jan 13, 2019 at 9:08 PM Isiah Meadows 
>> wrote:
>>
>>> As for security, scope control is usually the more important thing to
>>> monitor. That's covered in realms for the most part, but also a few other
>>> things. Stack traces don't play a major part here, and whenever untrusted
>>> calls need made and tracked through the stack, it's not that hard to just
>>> save and restore global data as needed.
>>> On Sun, Jan 13, 2019 at 22:05 Isiah Meadows 
>>> wrote:
>>>
 You may be interested in this:
 https://github.com/tc39/proposal-error-stacks
 On Sun, Jan 13, 2019 at 22:02 Ranando King  wrote:

> ES used to have Function.caller for traversing the call stack, but
> apparently this was very problematic for engine development and prevented
> various optimizations. So now it doesn't work in strict mode which makes 
> it
> useless for code involving `"use strict"` or `class`. One of the main use
> cases for such functionality was being able to determine where a given
> function was called from.
>
> I was thinking of a global static class that is able to uniquely
> identify each execution context on the call stack without giving any 
> access
> to the context objects themselves. I was thinking of maybe something like
> this:
>
> ```js
> class CallStackEntry {
>   #className;//Name of the class or null
>   #functionName; //Name of the function or null
>   #fileName; //Name of the source file or null
>   #line; //Source line number
>   #offset;   //Source character offset on the line
>   #id;   //Symbol
>   get fileName() { return this.#filename; }
>   get line() { return this.#line; }
>   get offset() { return this.#offset; }
>   get id() { return this.#id; }
>   constructor(_fileName, _line_, _offset, _id) {
> this.#fileName = _fileName;
> this.#line = _line;
> this.#offset = _offset;
> this.#id = _id;
>   }
> }
>
> class CallStack {
>   static #callStack = []; //Internally managed
>   static get stackLimit() {...}
>   static set stackLimit(v) {...}
>   static get stack() {
> //return the call stack as an array of CallStackEntry objects
>   }
> }
> ```
>
> With something like this, security-type software would be able to
> clearly identify functions without granting any access rights to the
> corresponding 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: New Proposal: ES Call Stack

[Isiah Meadows]

You could substitute a function parameter accepting an object here or a
class instance for globals to dodge this. Doesn't change my point.

Here's how you deal with permissions like that: have A know what data B is
allowed to access, then pass B an object with only that data. If necessary,
make the exposed methods form a closure over the relevant private data.

On Mon, Jan 14, 2019 at 00:50 Ranando King  wrote:

> That's all fine and dandy until you're dealing with a project that has a
> "no globals" mandate. The problem that I'd want to be able to solve is one
> of gaining and losing control during a single function's execution.
> For example: say function A is privileged, but function B is not. Function
> A calls function B with some data that B should only partially be able to
> access. Right now, that's hardly possible. There's no way for the data
> being passed to know if it is ok for B to use those functions or
> properties. If it was possible for the data methods to peek at the stack
> and recognize that the current function isn't privileged, then the problem
> is solved.
>
> I know class-fields will make this a little easier, but it doesn't
> solve the problem, especially when there's a "no constructors" mandate.
>
> On Sun, Jan 13, 2019 at 9:08 PM Isiah Meadows 
> wrote:
>
>> As for security, scope control is usually the more important thing to
>> monitor. That's covered in realms for the most part, but also a few other
>> things. Stack traces don't play a major part here, and whenever untrusted
>> calls need made and tracked through the stack, it's not that hard to just
>> save and restore global data as needed.
>> On Sun, Jan 13, 2019 at 22:05 Isiah Meadows 
>> wrote:
>>
>>> You may be interested in this:
>>> https://github.com/tc39/proposal-error-stacks
>>> On Sun, Jan 13, 2019 at 22:02 Ranando King  wrote:
>>>
 ES used to have Function.caller for traversing the call stack, but
 apparently this was very problematic for engine development and prevented
 various optimizations. So now it doesn't work in strict mode which makes it
 useless for code involving `"use strict"` or `class`. One of the main use
 cases for such functionality was being able to determine where a given
 function was called from.

 I was thinking of a global static class that is able to uniquely
 identify each execution context on the call stack without giving any access
 to the context objects themselves. I was thinking of maybe something like
 this:

 ```js
 class CallStackEntry {
   #className;//Name of the class or null
   #functionName; //Name of the function or null
   #fileName; //Name of the source file or null
   #line; //Source line number
   #offset;   //Source character offset on the line
   #id;   //Symbol
   get fileName() { return this.#filename; }
   get line() { return this.#line; }
   get offset() { return this.#offset; }
   get id() { return this.#id; }
   constructor(_fileName, _line_, _offset, _id) {
 this.#fileName = _fileName;
 this.#line = _line;
 this.#offset = _offset;
 this.#id = _id;
   }
 }

 class CallStack {
   static #callStack = []; //Internally managed
   static get stackLimit() {...}
   static set stackLimit(v) {...}
   static get stack() {
 //return the call stack as an array of CallStackEntry objects
   }
 }
 ```

 With something like this, security-type software would be able to
 clearly identify functions without granting any access rights to the
 corresponding 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: New Proposal: ES Call Stack

[Jordan Harband]

"who calls function B" has, and must have, no bearing on how function B
behaves. Every single call site that passes identical (`Object.is`)
arguments must behave the same. Am I misunderstanding what you mean?

On Sun, Jan 13, 2019 at 9:50 PM Ranando King  wrote:

> That's all fine and dandy until you're dealing with a project that has a
> "no globals" mandate. The problem that I'd want to be able to solve is one
> of gaining and losing control during a single function's execution.
> For example: say function A is privileged, but function B is not. Function
> A calls function B with some data that B should only partially be able to
> access. Right now, that's hardly possible. There's no way for the data
> being passed to know if it is ok for B to use those functions or
> properties. If it was possible for the data methods to peek at the stack
> and recognize that the current function isn't privileged, then the problem
> is solved.
>
> I know class-fields will make this a little easier, but it doesn't
> solve the problem, especially when there's a "no constructors" mandate.
>
> On Sun, Jan 13, 2019 at 9:08 PM Isiah Meadows 
> wrote:
>
>> As for security, scope control is usually the more important thing to
>> monitor. That's covered in realms for the most part, but also a few other
>> things. Stack traces don't play a major part here, and whenever untrusted
>> calls need made and tracked through the stack, it's not that hard to just
>> save and restore global data as needed.
>> On Sun, Jan 13, 2019 at 22:05 Isiah Meadows 
>> wrote:
>>
>>> You may be interested in this:
>>> https://github.com/tc39/proposal-error-stacks
>>> On Sun, Jan 13, 2019 at 22:02 Ranando King  wrote:
>>>
 ES used to have Function.caller for traversing the call stack, but
 apparently this was very problematic for engine development and prevented
 various optimizations. So now it doesn't work in strict mode which makes it
 useless for code involving `"use strict"` or `class`. One of the main use
 cases for such functionality was being able to determine where a given
 function was called from.

 I was thinking of a global static class that is able to uniquely
 identify each execution context on the call stack without giving any access
 to the context objects themselves. I was thinking of maybe something like
 this:

 ```js
 class CallStackEntry {
   #className;//Name of the class or null
   #functionName; //Name of the function or null
   #fileName; //Name of the source file or null
   #line; //Source line number
   #offset;   //Source character offset on the line
   #id;   //Symbol
   get fileName() { return this.#filename; }
   get line() { return this.#line; }
   get offset() { return this.#offset; }
   get id() { return this.#id; }
   constructor(_fileName, _line_, _offset, _id) {
 this.#fileName = _fileName;
 this.#line = _line;
 this.#offset = _offset;
 this.#id = _id;
   }
 }

 class CallStack {
   static #callStack = []; //Internally managed
   static get stackLimit() {...}
   static set stackLimit(v) {...}
   static get stack() {
 //return the call stack as an array of CallStackEntry objects
   }
 }
 ```

 With something like this, security-type software would be able to
 clearly identify functions without granting any access rights to the
 corresponding 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: New Proposal: ES Call Stack

[Ranando King]

That's all fine and dandy until you're dealing with a project that has a
"no globals" mandate. The problem that I'd want to be able to solve is one
of gaining and losing control during a single function's execution.
For example: say function A is privileged, but function B is not. Function
A calls function B with some data that B should only partially be able to
access. Right now, that's hardly possible. There's no way for the data
being passed to know if it is ok for B to use those functions or
properties. If it was possible for the data methods to peek at the stack
and recognize that the current function isn't privileged, then the problem
is solved.

I know class-fields will make this a little easier, but it doesn't
solve the problem, especially when there's a "no constructors" mandate.

On Sun, Jan 13, 2019 at 9:08 PM Isiah Meadows 
wrote:

> As for security, scope control is usually the more important thing to
> monitor. That's covered in realms for the most part, but also a few other
> things. Stack traces don't play a major part here, and whenever untrusted
> calls need made and tracked through the stack, it's not that hard to just
> save and restore global data as needed.
> On Sun, Jan 13, 2019 at 22:05 Isiah Meadows 
> wrote:
>
>> You may be interested in this:
>> https://github.com/tc39/proposal-error-stacks
>> On Sun, Jan 13, 2019 at 22:02 Ranando King  wrote:
>>
>>> ES used to have Function.caller for traversing the call stack, but
>>> apparently this was very problematic for engine development and prevented
>>> various optimizations. So now it doesn't work in strict mode which makes it
>>> useless for code involving `"use strict"` or `class`. One of the main use
>>> cases for such functionality was being able to determine where a given
>>> function was called from.
>>>
>>> I was thinking of a global static class that is able to uniquely
>>> identify each execution context on the call stack without giving any access
>>> to the context objects themselves. I was thinking of maybe something like
>>> this:
>>>
>>> ```js
>>> class CallStackEntry {
>>>   #className;//Name of the class or null
>>>   #functionName; //Name of the function or null
>>>   #fileName; //Name of the source file or null
>>>   #line; //Source line number
>>>   #offset;   //Source character offset on the line
>>>   #id;   //Symbol
>>>   get fileName() { return this.#filename; }
>>>   get line() { return this.#line; }
>>>   get offset() { return this.#offset; }
>>>   get id() { return this.#id; }
>>>   constructor(_fileName, _line_, _offset, _id) {
>>> this.#fileName = _fileName;
>>> this.#line = _line;
>>> this.#offset = _offset;
>>> this.#id = _id;
>>>   }
>>> }
>>>
>>> class CallStack {
>>>   static #callStack = []; //Internally managed
>>>   static get stackLimit() {...}
>>>   static set stackLimit(v) {...}
>>>   static get stack() {
>>> //return the call stack as an array of CallStackEntry objects
>>>   }
>>> }
>>> ```
>>>
>>> With something like this, security-type software would be able to
>>> clearly identify functions without granting any access rights to the
>>> corresponding 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: New Proposal: ES Call Stack

[Isiah Meadows]

As for security, scope control is usually the more important thing to
monitor. That's covered in realms for the most part, but also a few other
things. Stack traces don't play a major part here, and whenever untrusted
calls need made and tracked through the stack, it's not that hard to just
save and restore global data as needed.
On Sun, Jan 13, 2019 at 22:05 Isiah Meadows  wrote:

> You may be interested in this:
> https://github.com/tc39/proposal-error-stacks
> On Sun, Jan 13, 2019 at 22:02 Ranando King  wrote:
>
>> ES used to have Function.caller for traversing the call stack, but
>> apparently this was very problematic for engine development and prevented
>> various optimizations. So now it doesn't work in strict mode which makes it
>> useless for code involving `"use strict"` or `class`. One of the main use
>> cases for such functionality was being able to determine where a given
>> function was called from.
>>
>> I was thinking of a global static class that is able to uniquely identify
>> each execution context on the call stack without giving any access to the
>> context objects themselves. I was thinking of maybe something like this:
>>
>> ```js
>> class CallStackEntry {
>>   #className;//Name of the class or null
>>   #functionName; //Name of the function or null
>>   #fileName; //Name of the source file or null
>>   #line; //Source line number
>>   #offset;   //Source character offset on the line
>>   #id;   //Symbol
>>   get fileName() { return this.#filename; }
>>   get line() { return this.#line; }
>>   get offset() { return this.#offset; }
>>   get id() { return this.#id; }
>>   constructor(_fileName, _line_, _offset, _id) {
>> this.#fileName = _fileName;
>> this.#line = _line;
>> this.#offset = _offset;
>> this.#id = _id;
>>   }
>> }
>>
>> class CallStack {
>>   static #callStack = []; //Internally managed
>>   static get stackLimit() {...}
>>   static set stackLimit(v) {...}
>>   static get stack() {
>> //return the call stack as an array of CallStackEntry objects
>>   }
>> }
>> ```
>>
>> With something like this, security-type software would be able to clearly
>> identify functions without granting any access rights to the corresponding
>> 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: New Proposal: ES Call Stack

[Isiah Meadows]

You may be interested in this: https://github.com/tc39/proposal-error-stacks
On Sun, Jan 13, 2019 at 22:02 Ranando King  wrote:

> ES used to have Function.caller for traversing the call stack, but
> apparently this was very problematic for engine development and prevented
> various optimizations. So now it doesn't work in strict mode which makes it
> useless for code involving `"use strict"` or `class`. One of the main use
> cases for such functionality was being able to determine where a given
> function was called from.
>
> I was thinking of a global static class that is able to uniquely identify
> each execution context on the call stack without giving any access to the
> context objects themselves. I was thinking of maybe something like this:
>
> ```js
> class CallStackEntry {
>   #className;//Name of the class or null
>   #functionName; //Name of the function or null
>   #fileName; //Name of the source file or null
>   #line; //Source line number
>   #offset;   //Source character offset on the line
>   #id;   //Symbol
>   get fileName() { return this.#filename; }
>   get line() { return this.#line; }
>   get offset() { return this.#offset; }
>   get id() { return this.#id; }
>   constructor(_fileName, _line_, _offset, _id) {
> this.#fileName = _fileName;
> this.#line = _line;
> this.#offset = _offset;
> this.#id = _id;
>   }
> }
>
> class CallStack {
>   static #callStack = []; //Internally managed
>   static get stackLimit() {...}
>   static set stackLimit(v) {...}
>   static get stack() {
> //return the call stack as an array of CallStackEntry objects
>   }
> }
> ```
>
> With something like this, security-type software would be able to clearly
> identify functions without granting any access rights to the corresponding
> 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

New Proposal: ES Call Stack

[Ranando King]

ES used to have Function.caller for traversing the call stack, but
apparently this was very problematic for engine development and prevented
various optimizations. So now it doesn't work in strict mode which makes it
useless for code involving `"use strict"` or `class`. One of the main use
cases for such functionality was being able to determine where a given
function was called from.

I was thinking of a global static class that is able to uniquely identify
each execution context on the call stack without giving any access to the
context objects themselves. I was thinking of maybe something like this:

```js
class CallStackEntry {
  #className;//Name of the class or null
  #functionName; //Name of the function or null
  #fileName; //Name of the source file or null
  #line; //Source line number
  #offset;   //Source character offset on the line
  #id;   //Symbol
  get fileName() { return this.#filename; }
  get line() { return this.#line; }
  get offset() { return this.#offset; }
  get id() { return this.#id; }
  constructor(_fileName, _line_, _offset, _id) {
this.#fileName = _fileName;
this.#line = _line;
this.#offset = _offset;
this.#id = _id;
  }
}

class CallStack {
  static #callStack = []; //Internally managed
  static get stackLimit() {...}
  static set stackLimit(v) {...}
  static get stack() {
//return the call stack as an array of CallStackEntry objects
  }
}
```

With something like this, security-type software would be able to clearly
identify functions without granting any access rights to the corresponding
function.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: New Proposal: Placeholder syntax

[Andrew Kaiser]

thank you all for the feedback, I appreciate those who pointed out the
flaws in the logic. I can see that this is an ambiguous proposal. Though I
did not realize it at the time, this proposal is competing with
https://github.com/tc39/proposal-partial-application, as the two syntax's
cannot exist in the same language. I still find the scala-like pattern
useful, and not all hope is lost. There is a babel macro
https://www.npmjs.com/package/param.macro which was inspired by scala's `_`.

Side note, they solve the issue of `g(f(?))` creating either `x => g(f(x))`
or `g(x => f(x))` by splitting the logic into two different macros, `it`
and `_`.

```
import { _, it } from 'param.macro'

const arrayOfObj = [{ n: 1 }, { n: 2 }, { n: 3}]

arrayOfObj.map(it.n)
// yeilds
// arrayOfObj.map(x => x.n)

arrayOfObj.map(_.n)
// yeilds
// x => arrayOfObj.map(x.n)
```

If anyone is interested in keeping the proposal alive/modifying it, feel
free to put a pull request on my repo
https://github.com/andykais/proposal-placeholder-syntax. Otherwise, I don't
believe I see a lot of interest in it according to this discussion.


On Fri, Dec 7, 2018 at 5:51 PM Waldemar Horwat  wrote:

> On 11/28/2018 10:17 AM, Andrew Kaiser wrote:
> > Hi all,
> >
> > I have created a short proposal to introduce syntactic sugar for
> anonymous functions in a 'scala-like' manner, linked here
> https://github.com/andykais/proposal-placeholder-syntax.
> >
> > I am hoping to hear feedback on whether or not this is interesting to
> people, as well as feedback on the proposal itself (e.g. is there a better
> operator to use than ` * `)
>
> This is error-prone:
>
>const sum = numbers.reduce(? + ?)
> transforms into
>const sum = numbers.reduce((x, y) => x + y)
>
> but then:
>
>const identity = numbers.reduce(?)
> transforms into
>const identity = (x) => numbers.reduce(x)
> instead of the analogous
>const identity = numbers.reduce((x) => x)
>
> And what would
>const z = numbers.reduce(? + ? > 0)
> or
>const z = numbers.reduce(2*(? + ?))
> or
>const z = numbers.reduce(foo(? + ?))
> transform into?
>
>  Waldemar
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: New Proposal: Placeholder syntax

[Waldemar Horwat]

On 11/28/2018 10:17 AM, Andrew Kaiser wrote:

Hi all,

I have created a short proposal to introduce syntactic sugar for anonymous 
functions in a 'scala-like' manner, linked here 
https://github.com/andykais/proposal-placeholder-syntax.

I am hoping to hear feedback on whether or not this is interesting to people, 
as well as feedback on the proposal itself (e.g. is there a better operator to 
use than ` * `)


This is error-prone:

  const sum = numbers.reduce(? + ?)
transforms into
  const sum = numbers.reduce((x, y) => x + y)

but then:

  const identity = numbers.reduce(?)
transforms into
  const identity = (x) => numbers.reduce(x)
instead of the analogous
  const identity = numbers.reduce((x) => x)

And what would
  const z = numbers.reduce(? + ? > 0)
or
  const z = numbers.reduce(2*(? + ?))
or
  const z = numbers.reduce(foo(? + ?))
transform into?

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

Re: New: proposal-class-modifiers

[Ranando King]

> Can you please keep this extremely condescending tone out of these
discussions? I don't know how you expect people to get on board with your
proposals when you constantly imply that those that disagree with you don't
know what they are talking about.

My apologies if you thought my tone condescending. My intent was merely to
point out that assuming the constructor to be the correct point of focus
for the implementation of `abstract` will only lead to implementations that
don't work as desired. I tend to speak (and write) in a very matter-of-fact
tone for things that I have tested and proven to myself repeatedly. Again,
it wasn't my intention to do anything more than state the facts and explain
the dangers of potential misconceptions.

> A prototype with an entirely different constructor is an entirely
different class. The behavior of a constructor is critical to the behavior
of an instance of a class, and in an ideal world is responsible for
defining all of the own properties of the instance. I don't understand how
a prototype on its own could be considered to represent the class as a
whole.

I get what you're saying, and on that point, you're not wrong, especially
for base classes. However, consider the inheritance case. The instance
object, before any own properties can be attached, has the prototype of the
class and its base classes attached. Even if the constructors are empty,
the class is still complete. After construction of the instance object, the
job of the constructor can just as easily be performed by any other
function of the class. The constructor itself is simply a convenient place
to perform this initialization before any other code has the opportunity to
touch the instance. I don't mean to argue this point. I've already accepted
that my perspective on this is not the popular understanding. However,
every attempt I've made to hash out how things work (for several proposals)
using a constructor-first perspective led to unacceptable trade-offs and
complications.

> I'm not sure I see how that would be any different for intercepting the
`.prototype` access.

Whether it's the constructor or prototype, a private slot would need to be
used to mark the class as abstract. Since this proposal (currently) only
affects `class` definitions, and `class` definitions mark the `prototype`
as non-writable, non-configurable, there's no way for the original
constructor to have its prototype replaced. Even Proxy can't change this.
If the flag is put on the constructor, then it is easily bypassed by
manually creating a constructor function and copying the prototype object.
However, if the flag is placed on the prototype object itself, there is no
way to spoof it. This also makes it possible for `final` to prevent
`Object.create` and `Object.setPrototypeOf`, but I'm still waiting for
Isiah to convince me it's a good thing to do.

> Is `final` meant to mean that the prototype may never exist anywhere but
the head of the prototype chain, or just that a subclass may not be
constructed?

It's closer to the former than the latter. At present, I'm thinking this
should only affect classes, but if Isiah (or anyone else) comes up with a
good reason why it should also block `Object.create` and
`Object.setPrototypeOf`, then it would be completely the former. Just
preventing construction of a subclass instance doesn't seem to have much
merit to me.

On Sun, Dec 2, 2018 at 8:57 PM Logan Smyth  wrote:

> > Contrary to what you may have been led to believe, the definition of a
> class is its prototype. There are those who refuse to accept this reality,
> and that's fine. But if you make the wrong assumptions as a result of an
> incorrect understanding, the results won't turn out how you want.
>
> Can you please keep this extremely condescending tone out of these
> discussions? I don't know how you expect people to get on board with your
> proposals when you constantly imply that those that disagree with you don't
> know what they are talking about.
>
> > The constructor only comes into play after a new object has been created
> with the corresponding prototype attached.
>
> A prototype with an entirely different constructor is an entirely
> different class. The behavior of a constructor is critical to the behavior
> of an instance of a class, and in an ideal world is responsible for
> defining all of the own properties of the instance. I don't understand how
> a prototype on its own could be considered to represent the class as a
> whole.
>
> > Constructor comparisons can easily be spoofed simply by Proxying the
> constructor.
>
> I'm not sure I see how that would be any different for intercepting the
> `.prototype` access.
>
> > With `final`, the point is that a `class` that extends from a `fina

Re: New: proposal-class-modifiers

[Logan Smyth]

> Contrary to what you may have been led to believe, the definition of a
class is its prototype. There are those who refuse to accept this reality,
and that's fine. But if you make the wrong assumptions as a result of an
incorrect understanding, the results won't turn out how you want.

Can you please keep this extremely condescending tone out of these
discussions? I don't know how you expect people to get on board with your
proposals when you constantly imply that those that disagree with you don't
know what they are talking about.

> The constructor only comes into play after a new object has been created
with the corresponding prototype attached.

A prototype with an entirely different constructor is an entirely different
class. The behavior of a constructor is critical to the behavior of an
instance of a class, and in an ideal world is responsible for defining all
of the own properties of the instance. I don't understand how a prototype
on its own could be considered to represent the class as a whole.

> Constructor comparisons can easily be spoofed simply by Proxying the
constructor.

I'm not sure I see how that would be any different for intercepting the
`.prototype` access.

> With `final`, the point is that a `class` that extends from a `final
class` ***cannot be defined***, not simply "cannot be instantiated". Even
without instantiating, a defined `class` can still be used.

I don't disagree that it it would throw as early as possible in an ideal
world, just that it seems to complicate the implementation dramatically
with out a ton of benefit that I can see. I think it does depend on your
overall goal though. Is `final` meant to mean that the prototype may never
exist anywhere but the head of the prototype chain, or just that a subclass
may not be constructed? That I guess goes to Isiah's questions about
`Object.create` and such as well. It seems like 99% of the time I'd be much
more interested in preventing creation of subclasses. I don't particularly
care about the exact location of an object in the prototype chain.



On Sun, Dec 2, 2018 at 6:25 PM Ranando King  wrote:

> @Logan
>
> > It would not be good if you could sidestep `abstract` by taking the
> prototype from the class and making a new constructor for it.
>
> That's precisely why it's a prototype test and not a constructor test.
> Everything that defines the initial "shape" of the class is on the
> prototype. The constructor only comes into play after a new object has been
> created with the corresponding prototype attached. If the prototype of the
> constructor being called matches the prototype of newTarget, and that
> prototype has been flagged as abstract, the new object creation is halted
> immediately. Constructor comparisons can easily be spoofed simply by
> Proxying the constructor. Where target would be the un-Proxied constructor,
> newTarget would be the Proxy. They wouldn't match so the abstract test
> would fail and an object would be constructed.
>
> Contrary to what you may have been led to believe, the definition of a
> class is its prototype. There are those who refuse to accept this reality,
> and that's fine. But if you make the wrong assumptions as a result of an
> incorrect understanding, the results won't turn out how you want.
>
> With `final`, the point is that a `class` that extends from a `final
> class` ***cannot be defined***, not simply "cannot be instantiated". Even
> without instantiating, a defined `class` can still be used.
>
> >...it would essentially just be the negation of the check `abstract` was
> doing already.
>
> That's precisely correct. These 2 new tokens are the polar opposites of
> each other. One restricts construction to cases where the prototypes of
> `target` and `newTarget` match (`final`), while the other requires that
> they don't match (`abstract`). That's also the reason they cannot be used
> together.
>
> @Isiah
> Sounds like part of what you're looking for is abstract methods rather
> than an `abstract class`. I wasn't targeting that. If I were, that would be
> something to add to proposal-common-class-modifiers. If I were to look at
> what you're describing more holistically, you're looking for "interface", a
> way to set up a contract for what's supposed to be there and require it all
> to be present. I wasn't targeting that either. In fact, that would probably
> be a good proposal all by itself. I'll give an implementation for that some
> thought. However, with this proposal, all I'm thinking about is inheritance
> constraints.
>
> As for `final`, I need you to convince me that it's worth while preventing
> Object.create and Object.setPrototy

Re: New: proposal-class-modifiers

[Ranando King]

@Logan

> It would not be good if you could sidestep `abstract` by taking the
prototype from the class and making a new constructor for it.

That's precisely why it's a prototype test and not a constructor test.
Everything that defines the initial "shape" of the class is on the
prototype. The constructor only comes into play after a new object has been
created with the corresponding prototype attached. If the prototype of the
constructor being called matches the prototype of newTarget, and that
prototype has been flagged as abstract, the new object creation is halted
immediately. Constructor comparisons can easily be spoofed simply by
Proxying the constructor. Where target would be the un-Proxied constructor,
newTarget would be the Proxy. They wouldn't match so the abstract test
would fail and an object would be constructed.

Contrary to what you may have been led to believe, the definition of a
class is its prototype. There are those who refuse to accept this reality,
and that's fine. But if you make the wrong assumptions as a result of an
incorrect understanding, the results won't turn out how you want.

With `final`, the point is that a `class` that extends from a `final class`
***cannot be defined***, not simply "cannot be instantiated". Even without
instantiating, a defined `class` can still be used.

>...it would essentially just be the negation of the check `abstract` was
doing already.

That's precisely correct. These 2 new tokens are the polar opposites of
each other. One restricts construction to cases where the prototypes of
`target` and `newTarget` match (`final`), while the other requires that
they don't match (`abstract`). That's also the reason they cannot be used
together.

@Isiah
Sounds like part of what you're looking for is abstract methods rather than
an `abstract class`. I wasn't targeting that. If I were, that would be
something to add to proposal-common-class-modifiers. If I were to look at
what you're describing more holistically, you're looking for "interface", a
way to set up a contract for what's supposed to be there and require it all
to be present. I wasn't targeting that either. In fact, that would probably
be a good proposal all by itself. I'll give an implementation for that some
thought. However, with this proposal, all I'm thinking about is inheritance
constraints.

As for `final`, I need you to convince me that it's worth while preventing
Object.create and Object.setPrototype. It's shouldn't be that difficult to
do, but I don't have an understanding of why you'd want to. Especially when
you consider that when some form of private goes in (assuming it's not
Symbol.Private) class instances will be quite a bit different than vanilla
objects.

I get that `final` is something not seen in dynamic languages (outside the
JVM), but it is a useful tool in giving developers control over how their
code can be used. Isn't that part of the point of trying to implement
private data in ES?

On Sun, Dec 2, 2018 at 4:19 PM Isiah Meadows  wrote:

> @Logan If this helps explain my stance, I'm skeptical of the use, and
> it really disrupts the consistency of JS's object model quite a bit.
> It makes sense to enforce at a static level, but not really at a
> dynamic runtime level. Also, this is lacking precedent in other
> dynamic languages with classes: Python, Ruby, Smalltalk, Lua, Io, and
> pretty much every other dynamic language with class- or
> prototype-based inheritance (that wasn't made for the JVM) doesn't
> support final classes. Python (IIRC through a decorator) and Ruby
> support abstract methods, but not final classes/methods.
>
> -
>
> Isiah Meadows
> cont...@isiahmeadows.com
> www.isiahmeadows.com
>
> On Sun, Dec 2, 2018 at 5:10 PM Logan Smyth  wrote:
> >
> > Wouldn't it be better `abstract`'s `target.prototype ===
> newTarget.prototype` check to be `target === newTarget`? It's not really
> the prototype that is at issue here, it is the class constructor itself. It
> would not be good if you could sidestep `abstract` by taking the prototype
> from the class and making a new constructor for it.
> >
> > For `final` is it worth throwing an `extends` time vs just throwing when
> the class is instantiated? It seems like `final` would otherwise require
> new private state on the constructor itself, where otherwise it would
> essentially just be the negation of the check `abstract` was doing already.
> >
> > Also, if those make sense, what do we gain by having these be keywords
> instead of decorators?
> >
> > On Sun, Dec 2, 2018 at 1:43 PM Isiah Meadows 
> wrote:
> >>
> >> For `abstract`, I could see that being three things:
> >>
> &g

Re: New: proposal-class-modifiers

[Isiah Meadows]

@Logan If this helps explain my stance, I'm skeptical of the use, and
it really disrupts the consistency of JS's object model quite a bit.
It makes sense to enforce at a static level, but not really at a
dynamic runtime level. Also, this is lacking precedent in other
dynamic languages with classes: Python, Ruby, Smalltalk, Lua, Io, and
pretty much every other dynamic language with class- or
prototype-based inheritance (that wasn't made for the JVM) doesn't
support final classes. Python (IIRC through a decorator) and Ruby
support abstract methods, but not final classes/methods.

-

Isiah Meadows
cont...@isiahmeadows.com
www.isiahmeadows.com

On Sun, Dec 2, 2018 at 5:10 PM Logan Smyth  wrote:
>
> Wouldn't it be better `abstract`'s `target.prototype === newTarget.prototype` 
> check to be `target === newTarget`? It's not really the prototype that is at 
> issue here, it is the class constructor itself. It would not be good if you 
> could sidestep `abstract` by taking the prototype from the class and making a 
> new constructor for it.
>
> For `final` is it worth throwing an `extends` time vs just throwing when the 
> class is instantiated? It seems like `final` would otherwise require new 
> private state on the constructor itself, where otherwise it would essentially 
> just be the negation of the check `abstract` was doing already.
>
> Also, if those make sense, what do we gain by having these be keywords 
> instead of decorators?
>
> On Sun, Dec 2, 2018 at 1:43 PM Isiah Meadows  wrote:
>>
>> For `abstract`, I could see that being three things:
>>
>> - Throw a reference error if an abstract method is called with no concrete 
>> implementation
>> - Throw a type error if the constructor is called without its abstract 
>> methods implemented
>> - Throw a type error if a subclass fails to implement all remaining abstract 
>> methods and is not itself abstract
>>
>> Each of these could be reasonably tacked on at the end.
>>
>> For `final`, you'll need to create a way to block all means of 
>> `Object.create`, with class constructors being the sole exception. That 
>> complicates the mechanism tremendously, since prototype-based inheritance 
>> alone can't enforce this unless you make `Object.setPrototypeOf(obj, 
>> parent)` no longer directly equivalent to `obj.[[Prototype]] = parent`.
>> On Sun, Dec 2, 2018 at 16:28 Ranando King  wrote:
>>>
>>> Object.create and Object.setPrototypeOf operate on a different level than 
>>> what I'm targeting. I can conceive of a means to make even these functions 
>>> respect these tokens. However, if I were going to do that, I'd want these 
>>> tokens to be applicable to objects and functions directly. 
>>> Reflect.construct is essentially part of the process for `new` and would be 
>>> required to respect these tokens. I'm still open on how far the effect of 
>>> these tokens should extend.
>>>
>>> On Sun, Dec 2, 2018 at 3:20 PM Isiah Meadows  wrote:
>>>>
>>>> How would this interop with `Object.create`, `Reflect.construct`, and 
>>>> `Object.setPrototypeOf`?
>>>> On Sun, Dec 2, 2018 at 16:16 Ranando King  wrote:
>>>>>
>>>>> This proposal is intended to add `abstract` and `final` to `class` 
>>>>> definitions so as to modify the inheritability of a class.
>>>>>
>>>>> https://github.com/rdking/proposal-class-modifiers
>>>>> ___
>>>>> 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: New: proposal-class-modifiers

[Logan Smyth]

Wouldn't it be better `abstract`'s `target.prototype ===
newTarget.prototype` check to be `target === newTarget`? It's not really
the prototype that is at issue here, it is the class constructor itself. It
would not be good if you could sidestep `abstract` by taking the prototype
from the class and making a new constructor for it.

For `final` is it worth throwing an `extends` time vs just throwing when
the class is instantiated? It seems like `final` would otherwise require
new private state on the constructor itself, where otherwise it would
essentially just be the negation of the check `abstract` was doing already.

Also, if those make sense, what do we gain by having these be keywords
instead of decorators?

On Sun, Dec 2, 2018 at 1:43 PM Isiah Meadows  wrote:

> For `abstract`, I could see that being three things:
>
> - Throw a reference error if an abstract method is called with no concrete
> implementation
> - Throw a type error if the constructor is called without its abstract
> methods implemented
> - Throw a type error if a subclass fails to implement all remaining
> abstract methods and is not itself abstract
>
> Each of these could be reasonably tacked on at the end.
>
> For `final`, you'll need to create a way to block all means of
> `Object.create`, with class constructors being the sole exception. That
> complicates the mechanism tremendously, since prototype-based inheritance
> alone can't enforce this unless you make `Object.setPrototypeOf(obj,
> parent)` no longer directly equivalent to `obj.[[Prototype]] = parent`.
> On Sun, Dec 2, 2018 at 16:28 Ranando King  wrote:
>
>> Object.create and Object.setPrototypeOf operate on a different level than
>> what I'm targeting. I can conceive of a means to make even these functions
>> respect these tokens. However, if I were going to do that, I'd want these
>> tokens to be applicable to objects and functions directly.
>> Reflect.construct is essentially part of the process for `new` and would be
>> required to respect these tokens. I'm still open on how far the effect of
>> these tokens should extend.
>>
>> On Sun, Dec 2, 2018 at 3:20 PM Isiah Meadows 
>> wrote:
>>
>>> How would this interop with `Object.create`, `Reflect.construct`, and
>>> `Object.setPrototypeOf`?
>>> On Sun, Dec 2, 2018 at 16:16 Ranando King  wrote:
>>>
>>>> This proposal is intended to add `abstract` and `final` to `class`
>>>> definitions so as to modify the inheritability of a class.
>>>>
>>>> https://github.com/rdking/proposal-class-modifiers
>>>> ___
>>>> 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: New: proposal-class-modifiers

[Isiah Meadows]

For `abstract`, I could see that being three things:

- Throw a reference error if an abstract method is called with no concrete
implementation
- Throw a type error if the constructor is called without its abstract
methods implemented
- Throw a type error if a subclass fails to implement all remaining
abstract methods and is not itself abstract

Each of these could be reasonably tacked on at the end.

For `final`, you'll need to create a way to block all means of
`Object.create`, with class constructors being the sole exception. That
complicates the mechanism tremendously, since prototype-based inheritance
alone can't enforce this unless you make `Object.setPrototypeOf(obj,
parent)` no longer directly equivalent to `obj.[[Prototype]] = parent`.
On Sun, Dec 2, 2018 at 16:28 Ranando King  wrote:

> Object.create and Object.setPrototypeOf operate on a different level than
> what I'm targeting. I can conceive of a means to make even these functions
> respect these tokens. However, if I were going to do that, I'd want these
> tokens to be applicable to objects and functions directly.
> Reflect.construct is essentially part of the process for `new` and would be
> required to respect these tokens. I'm still open on how far the effect of
> these tokens should extend.
>
> On Sun, Dec 2, 2018 at 3:20 PM Isiah Meadows 
> wrote:
>
>> How would this interop with `Object.create`, `Reflect.construct`, and
>> `Object.setPrototypeOf`?
>> On Sun, Dec 2, 2018 at 16:16 Ranando King  wrote:
>>
>>> This proposal is intended to add `abstract` and `final` to `class`
>>> definitions so as to modify the inheritability of a class.
>>>
>>> https://github.com/rdking/proposal-class-modifiers
>>> ___
>>> 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: New: proposal-class-modifiers

[Ranando King]

Object.create and Object.setPrototypeOf operate on a different level than
what I'm targeting. I can conceive of a means to make even these functions
respect these tokens. However, if I were going to do that, I'd want these
tokens to be applicable to objects and functions directly.
Reflect.construct is essentially part of the process for `new` and would be
required to respect these tokens. I'm still open on how far the effect of
these tokens should extend.

On Sun, Dec 2, 2018 at 3:20 PM Isiah Meadows  wrote:

> How would this interop with `Object.create`, `Reflect.construct`, and
> `Object.setPrototypeOf`?
> On Sun, Dec 2, 2018 at 16:16 Ranando King  wrote:
>
>> This proposal is intended to add `abstract` and `final` to `class`
>> definitions so as to modify the inheritability of a class.
>>
>> https://github.com/rdking/proposal-class-modifiers
>> ___
>> 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: New: proposal-common-member-modifiers

[Ranando King]

I also agree that the community should have a hand in the process. I don't,
however, agree that waiting for the community to come to a consensus by
providing definitions that exist in the wild is a good idea. TC39 tends
toward not accepting proposals that break what already exists in the wild.
I'm submitting this proposal with the intent of having the community decide
on these important features **before** they're out in the wild so as to
prevent the natural confusion that will ensue as people release their own
spin on how these things should be defined. I'd even be happy with a set of
well-defined decorators, as long as they are a standard part of the
language. Whether or not the `@` is in front of them is of little merit to
me.

The point of the proposal is to make the standard parts of a property
descriptor also expressible in a `class` definition. This is something that
will be immediately desirable with any implementation of declarative data
members in a `class`.

On Sun, Dec 2, 2018 at 3:05 PM Augusto Moura 
wrote:

> Extracted from the proposal [1]:
> > Instead of waiting for the community to define and agree upon decorators
> for these purposes, why not define them now?
>
> In my opinion this is not how things should be done, in my opinion we
> actually should follow user-land patterns and help modifying/extending
> the language in this patterns pain points. We saw that in almost every
> new feature in the language since Harmony (not a coincidence, it's was
> actually decided to be this way), community agreement is a important
> factor in the process (I really don't know why it's not in the TC39
> process document [2], maybe is implied?). A lot of problems in
> Javascript ~and probably all other languages in existence~ arose from
> expected usefulness, just to be tagged as a foot gun or bad design by
> the community, and not used at all.
>
> That being said, I think decorators already provide all the need for
> this "runtime-modifiers" keywords, and new keyword-like modifiers will
> only add complexity to the language, as we would have 2 declarative
> ways of doing the same thing (or worse, the community decide in a
> different behavior for the analogue decorators, and probably one of
> the ways would be discouraged and become spec garbage).
>
> PS.: Sure there are cases were the community is really divided and
> things don't move because of that, and some of this cases are merged
> in the spec without total agreement at the end. But in my opinion this
> slow process and discussion is a good thing, we cannot merge something
> just to because it seems like a good feature. Also I'm not a TC39
> member, it's my opinion based in similar discussions in the past,
> maybe some real member can clarify it better or correct me if I'm
> wrong.
>
> [1] https://github.com/rdking/proposal-common-member-modifiers#motivation
> [2] https://tc39.github.io/process-document/
> Em dom, 2 de dez de 2018 às 04:49, Ranando King 
> escreveu:
> >
> > Since some form of data is going to land in ES class syntax, it would be
> a good idea if the capabilities of a property descriptor were also exposed
> for all public properties.
> >
> > https://github.com/rdking/proposal-common-member-modifiers
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> --
> Atenciosamente,
>
> Augusto Borges de Moura
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: New: proposal-class-modifiers

[Isiah Meadows]

How would this interop with `Object.create`, `Reflect.construct`, and
`Object.setPrototypeOf`?
On Sun, Dec 2, 2018 at 16:16 Ranando King  wrote:

> This proposal is intended to add `abstract` and `final` to `class`
> definitions so as to modify the inheritability of a class.
>
> https://github.com/rdking/proposal-class-modifiers
> ___
> 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: New: proposal-common-member-modifiers

[Isiah Meadows]

Decorators are stage 2. No major implementation implements them, and Babel
dropped them and had to completely reimplement their semantics after a
major semantic overhaul in the proposal.

https://github.com/tc39/proposal-decorators/

On Sun, Dec 2, 2018 at 15:15 Ranando King  wrote:

> I get that decorators "can" perform the same task, but these are features
> that are standard in the language today.
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

New: proposal-class-modifiers

[Ranando King]

This proposal is intended to add `abstract` and `final` to `class`
definitions so as to modify the inheritability of a class.

https://github.com/rdking/proposal-class-modifiers
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: New: proposal-common-member-modifiers

[Augusto Moura]

Extracted from the proposal [1]:
> Instead of waiting for the community to define and agree upon decorators for 
> these purposes, why not define them now?

In my opinion this is not how things should be done, in my opinion we
actually should follow user-land patterns and help modifying/extending
the language in this patterns pain points. We saw that in almost every
new feature in the language since Harmony (not a coincidence, it's was
actually decided to be this way), community agreement is a important
factor in the process (I really don't know why it's not in the TC39
process document [2], maybe is implied?). A lot of problems in
Javascript ~and probably all other languages in existence~ arose from
expected usefulness, just to be tagged as a foot gun or bad design by
the community, and not used at all.

That being said, I think decorators already provide all the need for
this "runtime-modifiers" keywords, and new keyword-like modifiers will
only add complexity to the language, as we would have 2 declarative
ways of doing the same thing (or worse, the community decide in a
different behavior for the analogue decorators, and probably one of
the ways would be discouraged and become spec garbage).

PS.: Sure there are cases were the community is really divided and
things don't move because of that, and some of this cases are merged
in the spec without total agreement at the end. But in my opinion this
slow process and discussion is a good thing, we cannot merge something
just to because it seems like a good feature. Also I'm not a TC39
member, it's my opinion based in similar discussions in the past,
maybe some real member can clarify it better or correct me if I'm
wrong.

[1] https://github.com/rdking/proposal-common-member-modifiers#motivation
[2] https://tc39.github.io/process-document/
Em dom, 2 de dez de 2018 às 04:49, Ranando King  escreveu:
>
> Since some form of data is going to land in ES class syntax, it would be a 
> good idea if the capabilities of a property descriptor were also exposed for 
> all public properties.
>
> https://github.com/rdking/proposal-common-member-modifiers
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



-- 
Atenciosamente,

Augusto Borges de Moura
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: New Proposal: Placeholder syntax

[Herbert Vojčík]

I find the "receiver" usage actually pretty useful. I know how I like to 
be able to do something like


  Smalltalk packages do: #commit

in Amber Smalltalk (even if it would be only a few chars longer

  Smalltalk packages do: [ :each | each commit ]

but readability is different, b/c the spirit of it is different, latter 
being explicitly imperative).


If partial application would win (why not), I would like to come up with 
receiver case as well in some other way. For example as:


  .x / .f()

instead of

  each => each.x / each => each.f()

IOW, would it be at least possible to sort-of future-proof ".xyz" for 
this kind of use?


Herby

Tab Atkins Jr. wrote on 28. 11. 2018 21:00:

Aside from the fact that this "placeholder" proposal addresses the
"receiver" and "operator" cases that partial-application explicitly
omits, the two proposals are exactly identical. They're not
"complementary", they're the same thing, just making a different
decision wrt complexity of some of the syntax cases. >
~TJ
___
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: New: proposal-common-member-modifiers

[Petter Envall]

I just want to make it perfectly clear to everyone that neither I am a 
member of TC39


Best regards
/p

On 2 December 2018 09:31:23 Isiah Meadows  wrote:


For one token (+ an import) more, you could use decorators instead.
And BTW, it's been suggested already that a standard decorator library
should exist, just IIUC (I'm not part of TC39) it's not yet determined
what should be in it.

-

Isiah Meadows
cont...@isiahmeadows.com
www.isiahmeadows.com

On Sun, Dec 2, 2018 at 2:25 AM Jacob Pratt  wrote:


I'm of the opinion this is what decorators are for.

On Sun, Dec 2, 2018, 01:49 Ranando King 

Since some form of data is going to land in ES class syntax, it would be a 
good idea if the capabilities of a property descriptor were also exposed 
for all public properties.


https://github.com/rdking/proposal-common-member-modifiers
___
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: New: proposal-common-member-modifiers

[Ranando King]

I get that decorators "can" perform the same task, but these are features
that are standard in the language today. Once we start defining data
properties on classes, there will be an immediate need to define the
attributes of those properties. Yes, decorators can fill the need, but
unless a standard library is provided to perform these tasks, there will
certainly be multiple different takes on how such decorators should work.
By defining them directly into the language like this, not only do we get a
well defined approach to declaring properties with the desired attributes,
but we avoid the additional complexity of decorator implementation for an
otherwise trivial task.

...at least, that's how I'm thinking of it. I'm also working on 1 last
proposal, proposal-class-modifiers with the intent of adding `abstract` and
`final` to class declarations where `abstract class` would prevent
instantiation of the class and `final` class would prevent inheritance of
the class.

On Sun, Dec 2, 2018 at 2:31 AM Isiah Meadows  wrote:

> For one token (+ an import) more, you could use decorators instead.
> And BTW, it's been suggested already that a standard decorator library
> should exist, just IIUC (I'm not part of TC39) it's not yet determined
> what should be in it.
>
> -
>
> Isiah Meadows
> cont...@isiahmeadows.com
> www.isiahmeadows.com
>
> On Sun, Dec 2, 2018 at 2:25 AM Jacob Pratt  wrote:
> >
> > I'm of the opinion this is what decorators are for.
> >
> > On Sun, Dec 2, 2018, 01:49 Ranando King  >>
> >> Since some form of data is going to land in ES class syntax, it would
> be a good idea if the capabilities of a property descriptor were also
> exposed for all public properties.
> >>
> >> https://github.com/rdking/proposal-common-member-modifiers
> >> ___
> >> 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: New: proposal-common-member-modifiers

[Isiah Meadows]

For one token (+ an import) more, you could use decorators instead.
And BTW, it's been suggested already that a standard decorator library
should exist, just IIUC (I'm not part of TC39) it's not yet determined
what should be in it.

-

Isiah Meadows
cont...@isiahmeadows.com
www.isiahmeadows.com

On Sun, Dec 2, 2018 at 2:25 AM Jacob Pratt  wrote:
>
> I'm of the opinion this is what decorators are for.
>
> On Sun, Dec 2, 2018, 01:49 Ranando King >
>> Since some form of data is going to land in ES class syntax, it would be a 
>> good idea if the capabilities of a property descriptor were also exposed for 
>> all public properties.
>>
>> https://github.com/rdking/proposal-common-member-modifiers
>> ___
>> 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: New: proposal-common-member-modifiers

[Jacob Pratt]

I'm of the opinion this is what decorators are for.

On Sun, Dec 2, 2018, 01:49 Ranando King  Since some form of data is going to land in ES class syntax, it would be a
> good idea if the capabilities of a property descriptor were also exposed
> for all public properties.
>
> https://github.com/rdking/proposal-common-member-modifiers
> ___
> 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

New: proposal-common-member-modifiers

[Ranando King]

Since some form of data is going to land in ES class syntax, it would be a
good idea if the capabilities of a property descriptor were also exposed
for all public properties.

https://github.com/rdking/proposal-common-member-modifiers
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: New Proposal: Number.range (Yes, range again)

[Cyril Auburtin]

cf https://github.com/tc39/proposal-slice-notation/issues/19 which would be
more powerful as a literal

On Thu, Nov 29, 2018 at 8:01 AM Jordan Harband  wrote:

> It's not a "standard library" unless every part of it has gone through a
> full standards process.
>
> On Wed, Nov 28, 2018 at 8:31 PM Jacob Pratt  wrote:
>
>> I'm not saying we should add it on to that proposal, but rather saying
>> that I think more effort should be put into a standard library where things
>> like this don't need to go through a full standards process. That's just my
>> opinion, and borderline on-topic for this specific suggestion.
>>
>> I'm absolutely in favor of having a `range` method, it's just _where_ it
>> should be that I differ.
>>
>> Jacob Pratt
>>
>> On Thu, Nov 29, 2018 at 4:29 AM Jack Works  wrote:
>>
>>> Oh, I'm not here to find out how to implement a range in detail. That's
>>> the trivial things, I want to first make it become a stage 0 proposal, then
>>> we can discuss if we need some overload or how to deal with the edge cases.
>>> Ps, does Pratt mean we should add it as a standard library in the stage
>>> 1 standard libraray proposal?
>>>
>>> On Thu, Nov 29, 2018, 12:18 Jacob Pratt  wrote:
>>>
>>>> Quick, simple TypeScript range function (with overloads, of course).
>>>>
>>>> ```
>>>> export function range(end: number): IterableIterator;
>>>> export function range(start: number, end: number):
>>>> IterableIterator;
>>>> export function range(start: number, end: number, step: number):
>>>> IterableIterator;
>>>> export function* range(start: number, end?: number, step?: number):
>>>> IterableIterator {
>>>>   // overload #1
>>>>   if (end === undefined) {
>>>> [start, end, step] = [0, start, 1];
>>>>   }
>>>>
>>>>   // overload #2
>>>>   if (step === undefined) {
>>>> step = Math.sign(end - start);
>>>>   }
>>>>
>>>>   // ensure we have the appropriate types
>>>>   if (typeof start !== 'number' || typeof end !== 'number' || typeof
>>>> step !== 'number') {
>>>> throw new TypeError('all parameters must be of type number');
>>>>   }
>>>>
>>>>   while ((start < end && step > 0) || (start > end && step < 0)) {
>>>> yield start;
>>>> start += step;
>>>>   }
>>>> }
>>>> ```
>>>>
>>>> IMO, we should focus on building up a JavaScript standard library that
>>>> has tons of useful utilities like this, rather than continue to add methods
>>>> onto namespaces. Perhaps that's just me, though.
>>>>
>>>> Jacob Pratt
>>>>
>>>> On Wed, Nov 28, 2018 at 9:33 PM Tab Atkins Jr. 
>>>> wrote:
>>>>
>>>>> I end up writing a range function in virtually every project I use, so
>>>>> yeah, I think this is worthwhile.
>>>>>
>>>>> My own preferences, based on Python precedence:
>>>>>
>>>>> Number.range(end) === Number.range(0, end, 1)
>>>>> Number.range(start, end) === Number.range(start, end,
>>>>> Math.sign(end-start))
>>>>> Number.range(start, end, step) => {
>>>>>   if start < end && step > 0: yield all (start + k*step), for k from 0
>>>>> to infinity, less than end
>>>>>   elif start > end && step < 0: yield all (start + k*step), for k from
>>>>> 0 to infinity, greater than end
>>>>>   else: yield nothing
>>>>> }
>>>>>
>>>>> So:
>>>>> * [...Number.range(5)] evaluates to [0, 1, 2, 3, 4]
>>>>> * [...Number.range(0)] evaluates to []
>>>>> * [...Number.range(-5)] evaluates to []
>>>>> * [...Number.range(1, -3)] evaluates to [1, 0, -1, -2]
>>>>> * [...Number.range(-3, 1)] evaluates to [-3, -2, -1, 0]
>>>>> * [...Number.range(1, 1)] evaluates to []
>>>>> * [...Number.range(0, 10, 5)] evaluates to [0, 5]
>>>>> * [...Number.range(0, 10, -5)] evaluates to []
>>>>>
>>>>> ~TJ
>>>>>
>>>> ___
>>>>> 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: New Proposal: Number.range (Yes, range again)

[Jordan Harband]

It's not a "standard library" unless every part of it has gone through a
full standards process.

On Wed, Nov 28, 2018 at 8:31 PM Jacob Pratt  wrote:

> I'm not saying we should add it on to that proposal, but rather saying
> that I think more effort should be put into a standard library where things
> like this don't need to go through a full standards process. That's just my
> opinion, and borderline on-topic for this specific suggestion.
>
> I'm absolutely in favor of having a `range` method, it's just _where_ it
> should be that I differ.
>
> Jacob Pratt
>
> On Thu, Nov 29, 2018 at 4:29 AM Jack Works  wrote:
>
>> Oh, I'm not here to find out how to implement a range in detail. That's
>> the trivial things, I want to first make it become a stage 0 proposal, then
>> we can discuss if we need some overload or how to deal with the edge cases.
>> Ps, does Pratt mean we should add it as a standard library in the stage 1
>> standard libraray proposal?
>>
>> On Thu, Nov 29, 2018, 12:18 Jacob Pratt  wrote:
>>
>>> Quick, simple TypeScript range function (with overloads, of course).
>>>
>>> ```
>>> export function range(end: number): IterableIterator;
>>> export function range(start: number, end: number):
>>> IterableIterator;
>>> export function range(start: number, end: number, step: number):
>>> IterableIterator;
>>> export function* range(start: number, end?: number, step?: number):
>>> IterableIterator {
>>>   // overload #1
>>>   if (end === undefined) {
>>> [start, end, step] = [0, start, 1];
>>>   }
>>>
>>>   // overload #2
>>>   if (step === undefined) {
>>> step = Math.sign(end - start);
>>>   }
>>>
>>>   // ensure we have the appropriate types
>>>   if (typeof start !== 'number' || typeof end !== 'number' || typeof
>>> step !== 'number') {
>>> throw new TypeError('all parameters must be of type number');
>>>   }
>>>
>>>   while ((start < end && step > 0) || (start > end && step < 0)) {
>>> yield start;
>>> start += step;
>>>   }
>>> }
>>> ```
>>>
>>> IMO, we should focus on building up a JavaScript standard library that
>>> has tons of useful utilities like this, rather than continue to add methods
>>> onto namespaces. Perhaps that's just me, though.
>>>
>>> Jacob Pratt
>>>
>>> On Wed, Nov 28, 2018 at 9:33 PM Tab Atkins Jr. 
>>> wrote:
>>>
>>>> I end up writing a range function in virtually every project I use, so
>>>> yeah, I think this is worthwhile.
>>>>
>>>> My own preferences, based on Python precedence:
>>>>
>>>> Number.range(end) === Number.range(0, end, 1)
>>>> Number.range(start, end) === Number.range(start, end,
>>>> Math.sign(end-start))
>>>> Number.range(start, end, step) => {
>>>>   if start < end && step > 0: yield all (start + k*step), for k from 0
>>>> to infinity, less than end
>>>>   elif start > end && step < 0: yield all (start + k*step), for k from
>>>> 0 to infinity, greater than end
>>>>   else: yield nothing
>>>> }
>>>>
>>>> So:
>>>> * [...Number.range(5)] evaluates to [0, 1, 2, 3, 4]
>>>> * [...Number.range(0)] evaluates to []
>>>> * [...Number.range(-5)] evaluates to []
>>>> * [...Number.range(1, -3)] evaluates to [1, 0, -1, -2]
>>>> * [...Number.range(-3, 1)] evaluates to [-3, -2, -1, 0]
>>>> * [...Number.range(1, 1)] evaluates to []
>>>> * [...Number.range(0, 10, 5)] evaluates to [0, 5]
>>>> * [...Number.range(0, 10, -5)] evaluates to []
>>>>
>>>> ~TJ
>>>>
>>> ___
>>>> 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: New Proposal: Number.range (Yes, range again)

[Jacob Pratt]

I'm not saying we should add it on to that proposal, but rather saying that
I think more effort should be put into a standard library where things like
this don't need to go through a full standards process. That's just my
opinion, and borderline on-topic for this specific suggestion.

I'm absolutely in favor of having a `range` method, it's just _where_ it
should be that I differ.

Jacob Pratt

On Thu, Nov 29, 2018 at 4:29 AM Jack Works  wrote:

> Oh, I'm not here to find out how to implement a range in detail. That's
> the trivial things, I want to first make it become a stage 0 proposal, then
> we can discuss if we need some overload or how to deal with the edge cases.
> Ps, does Pratt mean we should add it as a standard library in the stage 1
> standard libraray proposal?
>
> On Thu, Nov 29, 2018, 12:18 Jacob Pratt  wrote:
>
>> Quick, simple TypeScript range function (with overloads, of course).
>>
>> ```
>> export function range(end: number): IterableIterator;
>> export function range(start: number, end: number):
>> IterableIterator;
>> export function range(start: number, end: number, step: number):
>> IterableIterator;
>> export function* range(start: number, end?: number, step?: number):
>> IterableIterator {
>>   // overload #1
>>   if (end === undefined) {
>> [start, end, step] = [0, start, 1];
>>   }
>>
>>   // overload #2
>>   if (step === undefined) {
>> step = Math.sign(end - start);
>>   }
>>
>>   // ensure we have the appropriate types
>>   if (typeof start !== 'number' || typeof end !== 'number' || typeof step
>> !== 'number') {
>> throw new TypeError('all parameters must be of type number');
>>   }
>>
>>   while ((start < end && step > 0) || (start > end && step < 0)) {
>> yield start;
>> start += step;
>>   }
>> }
>> ```
>>
>> IMO, we should focus on building up a JavaScript standard library that
>> has tons of useful utilities like this, rather than continue to add methods
>> onto namespaces. Perhaps that's just me, though.
>>
>> Jacob Pratt
>>
>> On Wed, Nov 28, 2018 at 9:33 PM Tab Atkins Jr. 
>> wrote:
>>
>>> I end up writing a range function in virtually every project I use, so
>>> yeah, I think this is worthwhile.
>>>
>>> My own preferences, based on Python precedence:
>>>
>>> Number.range(end) === Number.range(0, end, 1)
>>> Number.range(start, end) === Number.range(start, end,
>>> Math.sign(end-start))
>>> Number.range(start, end, step) => {
>>>   if start < end && step > 0: yield all (start + k*step), for k from 0
>>> to infinity, less than end
>>>   elif start > end && step < 0: yield all (start + k*step), for k from
>>> 0 to infinity, greater than end
>>>   else: yield nothing
>>> }
>>>
>>> So:
>>> * [...Number.range(5)] evaluates to [0, 1, 2, 3, 4]
>>> * [...Number.range(0)] evaluates to []
>>> * [...Number.range(-5)] evaluates to []
>>> * [...Number.range(1, -3)] evaluates to [1, 0, -1, -2]
>>> * [...Number.range(-3, 1)] evaluates to [-3, -2, -1, 0]
>>> * [...Number.range(1, 1)] evaluates to []
>>> * [...Number.range(0, 10, 5)] evaluates to [0, 5]
>>> * [...Number.range(0, 10, -5)] evaluates to []
>>>
>>> ~TJ
>>>
>> ___
>>> 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: New Proposal: Number.range (Yes, range again)

[Jack Works]

Oh, I'm not here to find out how to implement a range in detail. That's the
trivial things, I want to first make it become a stage 0 proposal, then we
can discuss if we need some overload or how to deal with the edge cases.
Ps, does Pratt mean we should add it as a standard library in the stage 1
standard libraray proposal?

On Thu, Nov 29, 2018, 12:18 Jacob Pratt  wrote:

> Quick, simple TypeScript range function (with overloads, of course).
>
> ```
> export function range(end: number): IterableIterator;
> export function range(start: number, end: number):
> IterableIterator;
> export function range(start: number, end: number, step: number):
> IterableIterator;
> export function* range(start: number, end?: number, step?: number):
> IterableIterator {
>   // overload #1
>   if (end === undefined) {
> [start, end, step] = [0, start, 1];
>   }
>
>   // overload #2
>   if (step === undefined) {
> step = Math.sign(end - start);
>   }
>
>   // ensure we have the appropriate types
>   if (typeof start !== 'number' || typeof end !== 'number' || typeof step
> !== 'number') {
> throw new TypeError('all parameters must be of type number');
>   }
>
>   while ((start < end && step > 0) || (start > end && step < 0)) {
> yield start;
> start += step;
>   }
> }
> ```
>
> IMO, we should focus on building up a JavaScript standard library that has
> tons of useful utilities like this, rather than continue to add methods
> onto namespaces. Perhaps that's just me, though.
>
> Jacob Pratt
>
> On Wed, Nov 28, 2018 at 9:33 PM Tab Atkins Jr. 
> wrote:
>
>> I end up writing a range function in virtually every project I use, so
>> yeah, I think this is worthwhile.
>>
>> My own preferences, based on Python precedence:
>>
>> Number.range(end) === Number.range(0, end, 1)
>> Number.range(start, end) === Number.range(start, end,
>> Math.sign(end-start))
>> Number.range(start, end, step) => {
>>   if start < end && step > 0: yield all (start + k*step), for k from 0
>> to infinity, less than end
>>   elif start > end && step < 0: yield all (start + k*step), for k from
>> 0 to infinity, greater than end
>>   else: yield nothing
>> }
>>
>> So:
>> * [...Number.range(5)] evaluates to [0, 1, 2, 3, 4]
>> * [...Number.range(0)] evaluates to []
>> * [...Number.range(-5)] evaluates to []
>> * [...Number.range(1, -3)] evaluates to [1, 0, -1, -2]
>> * [...Number.range(-3, 1)] evaluates to [-3, -2, -1, 0]
>> * [...Number.range(1, 1)] evaluates to []
>> * [...Number.range(0, 10, 5)] evaluates to [0, 5]
>> * [...Number.range(0, 10, -5)] evaluates to []
>>
>> ~TJ
>>
> ___
>> 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: New Proposal: Number.range (Yes, range again)

[Jacob Pratt]

Quick, simple TypeScript range function (with overloads, of course).

```
export function range(end: number): IterableIterator;
export function range(start: number, end: number): IterableIterator;
export function range(start: number, end: number, step: number):
IterableIterator;
export function* range(start: number, end?: number, step?: number):
IterableIterator {
  // overload #1
  if (end === undefined) {
[start, end, step] = [0, start, 1];
  }

  // overload #2
  if (step === undefined) {
step = Math.sign(end - start);
  }

  // ensure we have the appropriate types
  if (typeof start !== 'number' || typeof end !== 'number' || typeof step
!== 'number') {
throw new TypeError('all parameters must be of type number');
  }

  while ((start < end && step > 0) || (start > end && step < 0)) {
yield start;
start += step;
  }
}
```

IMO, we should focus on building up a JavaScript standard library that has
tons of useful utilities like this, rather than continue to add methods
onto namespaces. Perhaps that's just me, though.

Jacob Pratt

On Wed, Nov 28, 2018 at 9:33 PM Tab Atkins Jr.  wrote:

> I end up writing a range function in virtually every project I use, so
> yeah, I think this is worthwhile.
>
> My own preferences, based on Python precedence:
>
> Number.range(end) === Number.range(0, end, 1)
> Number.range(start, end) === Number.range(start, end, Math.sign(end-start))
> Number.range(start, end, step) => {
>   if start < end && step > 0: yield all (start + k*step), for k from 0
> to infinity, less than end
>   elif start > end && step < 0: yield all (start + k*step), for k from
> 0 to infinity, greater than end
>   else: yield nothing
> }
>
> So:
> * [...Number.range(5)] evaluates to [0, 1, 2, 3, 4]
> * [...Number.range(0)] evaluates to []
> * [...Number.range(-5)] evaluates to []
> * [...Number.range(1, -3)] evaluates to [1, 0, -1, -2]
> * [...Number.range(-3, 1)] evaluates to [-3, -2, -1, 0]
> * [...Number.range(1, 1)] evaluates to []
> * [...Number.range(0, 10, 5)] evaluates to [0, 5]
> * [...Number.range(0, 10, -5)] evaluates to []
>
> ~TJ
> ___
> 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: New Proposal: Placeholder syntax

[Ron Buckton]

Partial application chose to limit the scope of `?` to argument positions in an 
argument list for a number of reasons. The primary being this case (assuming 
arbitrary expressions were allowed):

```js
let i = 0;
const g = f({ x: i++, y: ? });
```

The goal of partial application was to “fix” non-placeholder arguments at the 
time the partial function result is bound. This means that `i++` above should 
evaluate only once. However, if we allowed placeholders in arbitrary parts of 
an expression, to preserve this behavior we would have to be able to “partially 
fix” any arbitrary expression (such as the property names and property values 
of the object literal above). Various committee members indicated that they 
were very much opposed to this kind of partial fixing.

The other problem with placeholders is scoping. The above example could have 
two interpretations: One where `g` is a partial function for `f` with an 
argument that fills in the `y` property, and one where `f` is called with an 
object that has a property `y` that is an identity function.

A placeholder as an arbitrary expression is also complicated by something like 
`g(f(?))`. If `?` is an arbitrary expression, you need to syntactically mark 
the boundary of the expression, otherwise a user could expect the result to be 
either `x => g(f(x))` or `g(x => f(x))`. In Scala’s case, you end up needing to 
use a block-style for these cases. If `?` is scoped to its immediate argument 
list and does not allow arbitrary expressions, then there becomes only one 
possible interpretation (in this case, `g(x => f(x))`). In this way, partial 
application is like a more powerful syntactic variation of 
Function.prototype.bind, as Function.prototype.bind always fixes arguments in 
the function’s immediate argument list.

Ron

From: es-discuss  On Behalf Of Andrew Kaiser
Sent: Wednesday, November 28, 2018 11:57 AM
To: ljh...@gmail.com
Cc: es-discuss@mozilla.org
Subject: Re: New Proposal: Placeholder syntax

This proposal also works with simple math operations and for accessing fields 
on objects. The partial application lists these expressions as invalid.

```js
// invalid
f(x + ?)  // `?` not in top-level Arguments of call
x + ? // `?` not in top-level Arguments of call
?.f() // `?` not in top-level Arguments of call
```
Admittedly they chose not to include these operations because of the complexity 
it would add to the transpilation, but the placeholder proposal is simpler in 
nature. The partial application proposal alters what is returned by a function 
call, the placeholder proposal replaces an argument inline, and the value a 
called function returns does not change.

On Wed, Nov 28, 2018 at 2:35 PM Jordan Harband 
mailto:ljh...@gmail.com>> wrote:
It seems like the partial application proposal covers all of the use cases of 
yours, at a first glance. What does yours offer that partial application does 
not?

On Wed, Nov 28, 2018 at 11:23 AM Andrew Kaiser 
mailto:kaisea@gmail.com>> wrote:
Do you see a way these proposals can work together? I believe they are solving 
different needs. Both proposals produce a new anonymous function, but partial 
application deals with currying, while the placeholder proposal tries to 
prevent writing a function at all. I can actually see the two working together:

```js
const filenames = ['file1.txt', 'file2.txt' 'output.log' ]
const fileContainsContent = (filename, content) => 
fs.readFileSync(filename).toString().includes(content)

const fileSearchers = filenames.map(fileContainsContent(*, ?))
const filesContainingSearch = fileSearchers.filter(searcher => 
searcher('foobar'))
```

This isn't a very useful example, but you can see how the proposals differ 
accomplish different things

On Wed, Nov 28, 2018 at 1:30 PM Jordan Harband 
mailto:ljh...@gmail.com>> wrote:
You may be interested in the partial application proposal: 
https://github.com/tc39/proposal-partial-application<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftc39%2Fproposal-partial-application&data=02%7C01%7Cron.buckton%40microsoft.com%7C3f77a64eda334aa76bd708d6556ba4d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636790318211957611&sdata=Esl%2F8p6N7B8pJuXqyycMfmhIB38h67zrAwj9CzQLieU%3D&reserved=0>

On Wed, Nov 28, 2018 at 10:17 AM Andrew Kaiser 
mailto:kaisea@gmail.com>> wrote:
Hi all,

I have created a short proposal to introduce syntactic sugar for anonymous 
functions in a 'scala-like' manner, linked here 
https://github.com/andykais/proposal-placeholder-syntax<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fandykais%2Fproposal-placeholder-syntax&data=02%7C01%7Cron.buckton%40microsoft.com%7C3f77a64eda334aa76bd708d6556ba4d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636790318211967623&sdata=UPfh4NQUw38f03Qq92xZWVj2%2BEH3esAg6SXh

Re: New: proposal-safe-prototype

[Ranando King]

> Should the last line trigger copy-on-write around `a.__proto__`?

Yes. I get that you think of this as "dreadful action-at-a-distance", but
that kind of thing already happens any time the primitive value (including
root-level object references) of a property on the prototype changes. The
intent of this proposal is to treat the whole of the object that exists on
a property of `__proto__` as if it were a primitive. Any attempt to change
it in part or whole forces it to become an instance-specific value first.
The technique used in the example of this proposal ensures that object
reference in `b` isn't invalidated in the process.

The net result is that you don't get to **accidentally** mutate a
prototype. If you want to change some value in a prototype, get access to
it directly first. Using your example, do this:
```js
var a = { __proto__: { foo: { bar: 2 } } } with safe-prototype;
var b = Object.getPrototypeOf(a).foo;
b.bar = 3;
```
This would skip the new behavior, causing the prototype to be modified
directly.

> Unless you have deep knowledge of the internal state and/or the
implementation of the modified object (which you don’t have in case of a
user-implementated one), you cannot reliably detect when an object is
mutated.

I accounted for that with Symbol.UnsafeProto. All prototypes of native
functions will have this flag on them, preventing any attempt at the new
behavior. Further, any behavior that cannot be caught by a Membrane is
beyond the scope of this effort. Given the insanely flexible nature of ES,
it's unrealistic to thing that 100% of all possible implementation details
can be tracked. However, what this proposal seeks to provide is elimination
of the foot-gun for the most common cases. Even in non-interpreted
languages, some objects are impossible to clone completely due to the use
of external resources. This can't be helped.

For objects having such complicated implementations, the developer will
always be able to add Symbol.UnsafeProto to ensure that no attempt to
duplicate it ever occurs. Proper use of the 2 symbols will ensure that
whenever reasonable, the foot-gun cannot appear.

On Wed, Nov 28, 2018 at 3:36 PM Claude Pache  wrote:

> Sorry, I didn’t read the thread thoroughly (so maybe I’ll repeat someone).
> But here are some serious  issues with your proposal:
>
> --
>
> 1. Assignment of properties deep in the object hierarchy split in two
> instructions:
>
> ```js
> var a = { __proto__: { foo: { bar: 2 } } } with safe-prototype;
> var b = a.foo;
> b.bar = 3;
> ```
> Should the last line trigger copy-on-write around `a.__proto__`?
>
> If you say ”no”, it means that the meaning of the code is changed
> unexpectedly with an apparent innocuous code refactoring.
>
> If you say ”yes”, it is dreadful action-at-distance, because the two last
> lines of code may be very distant, indeed even in two distinct files. — It
> would be less an issue if prototypes were, say, just abstract templates.
> But they are not, they are concrete objects, so:
>
> ```js
> var proto = { foo: { bar: 2 } };
> var a1 = { __proto__: proto } with safe-prototype;
> var a2 = { __proto__: proto } with safe-prototype;
> var b1 = a1.foo;
> var b2 = a2.foo
> b1 === b2; // true
> b1.bar = 3;
> b1 === b2; // ???
> ```
>
> --
>
> 2. Object mutations unrelated to the value of its properties:
>
> ```js
> var a = { __proto__: { foo: new Map([ [ 'bar', 2 ] ]) } } with
> safe-prototype;
> a.foo.set('bar', 3);
> ```
>
> Unless you have deep knowledge of the internal state and/or the
> implementation of the modified object (which you don’t have in case of a
> user-implementated one), you cannot reliably detect when an object is
> mutated.
>
> Note the subtle difference between:
> *  `[].push(1)` — You will detect object mutation, because it will add a
> concrete property on the Array object.
> * `(new Set).add(1)` — You won’t detect mutation, because only internal
> state of the Set object is modified.
> * `(new RandomUserDefinedCollection).put(1)` — That depends on the
> implementation of the `RandomUserDefinedCollection` class.
>
>
>
> —Claude
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: New: proposal-safe-prototype

[Claude Pache]

Sorry, I didn’t read the thread thoroughly (so maybe I’ll repeat someone). But 
here are some serious  issues with your proposal:

--

1. Assignment of properties deep in the object hierarchy split in two 
instructions:

```js
var a = { __proto__: { foo: { bar: 2 } } } with safe-prototype;
var b = a.foo;
b.bar = 3;
```
Should the last line trigger copy-on-write around `a.__proto__`?

If you say ”no”, it means that the meaning of the code is changed unexpectedly 
with an apparent innocuous code refactoring.

If you say ”yes”, it is dreadful action-at-distance, because the two last lines 
of code may be very distant, indeed even in two distinct files. — It would be 
less an issue if prototypes were, say, just abstract templates. But they are 
not, they are concrete objects, so:

```js
var proto = { foo: { bar: 2 } };
var a1 = { __proto__: proto } with safe-prototype;
var a2 = { __proto__: proto } with safe-prototype;
var b1 = a1.foo;
var b2 = a2.foo
b1 === b2; // true
b1.bar = 3;
b1 === b2; // ???
```

--

2. Object mutations unrelated to the value of its properties:

```js
var a = { __proto__: { foo: new Map([ [ 'bar', 2 ] ]) } } with safe-prototype;
a.foo.set('bar', 3);
```

Unless you have deep knowledge of the internal state and/or the implementation 
of the modified object (which you don’t have in case of a user-implementated 
one), you cannot reliably detect when an object is mutated.

Note the subtle difference between:
*  `[].push(1)` — You will detect object mutation, because it will add a 
concrete property on the Array object.
* `(new Set).add(1)` — You won’t detect mutation, because only internal state 
of the Set object is modified.
* `(new RandomUserDefinedCollection).put(1)` — That depends on the 
implementation of the `RandomUserDefinedCollection` class.



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

Re: New Proposal: Number.range (Yes, range again)

[Tab Atkins Jr.]

I end up writing a range function in virtually every project I use, so
yeah, I think this is worthwhile.

My own preferences, based on Python precedence:

Number.range(end) === Number.range(0, end, 1)
Number.range(start, end) === Number.range(start, end, Math.sign(end-start))
Number.range(start, end, step) => {
  if start < end && step > 0: yield all (start + k*step), for k from 0
to infinity, less than end
  elif start > end && step < 0: yield all (start + k*step), for k from
0 to infinity, greater than end
  else: yield nothing
}

So:
* [...Number.range(5)] evaluates to [0, 1, 2, 3, 4]
* [...Number.range(0)] evaluates to []
* [...Number.range(-5)] evaluates to []
* [...Number.range(1, -3)] evaluates to [1, 0, -1, -2]
* [...Number.range(-3, 1)] evaluates to [-3, -2, -1, 0]
* [...Number.range(1, 1)] evaluates to []
* [...Number.range(0, 10, 5)] evaluates to [0, 5]
* [...Number.range(0, 10, -5)] evaluates to []

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

Re: New Proposal: Placeholder syntax

[Claude Pache]

> Le 28 nov. 2018 à 19:17, Andrew Kaiser  a écrit :
> 
> Hi all,
> 
> I have created a short proposal to introduce syntactic sugar for anonymous 
> functions in a 'scala-like' manner, linked here 
> https://github.com/andykais/proposal-placeholder-syntax 
> .
> 
> I am hoping to hear feedback on whether or not this is interesting to people, 
> as well as feedback on the proposal itself (e.g. is there a better operator 
> to use than ` * `)


See the previous discussion on this topic:

https://esdiscuss.org/topic/syntax-proposal-anonymous-arguments

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

Re: New Proposal: Placeholder syntax

[Tab Atkins Jr.]

Aside from the fact that this "placeholder" proposal addresses the
"receiver" and "operator" cases that partial-application explicitly
omits, the two proposals are exactly identical. They're not
"complementary", they're the same thing, just making a different
decision wrt complexity of some of the syntax cases.

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

Re: New Proposal: Placeholder syntax

[Andrew Kaiser]

This proposal also works with simple math operations and for accessing
fields on objects. The partial application lists these expressions as
invalid.

```js
// invalid
f(x + ?)  // `?` not in top-level Arguments of call
x + ? // `?` not in top-level Arguments of call
?.f() // `?` not in top-level Arguments of call
```
Admittedly they chose not to include these operations because of the
complexity it would add to the transpilation, but the placeholder proposal
is simpler in nature. The partial application proposal alters what is
returned by a function call, the placeholder proposal replaces an argument
inline, and the value a called function returns does not change.

On Wed, Nov 28, 2018 at 2:35 PM Jordan Harband  wrote:

> It seems like the partial application proposal covers all of the use cases
> of yours, at a first glance. What does yours offer that partial application
> does not?
>
> On Wed, Nov 28, 2018 at 11:23 AM Andrew Kaiser 
> wrote:
>
>> Do you see a way these proposals can work together? I believe they are
>> solving different needs. Both proposals produce a new anonymous function,
>> but partial application deals with currying, while the placeholder proposal
>> tries to prevent writing a function at all. I can actually see the two
>> working together:
>>
>> ```js
>> const filenames = ['file1.txt', 'file2.txt' 'output.log' ]
>> const fileContainsContent = (filename, content) =>
>> fs.readFileSync(filename).toString().includes(content)
>>
>> const fileSearchers = filenames.map(fileContainsContent(*, ?))
>> const filesContainingSearch = fileSearchers.filter(searcher =>
>> searcher('foobar'))
>> ```
>>
>> This isn't a very useful example, but you can see how the proposals
>> differ accomplish different things
>>
>> On Wed, Nov 28, 2018 at 1:30 PM Jordan Harband  wrote:
>>
>>> You may be interested in the partial application proposal:
>>> https://github.com/tc39/proposal-partial-application
>>>
>>> On Wed, Nov 28, 2018 at 10:17 AM Andrew Kaiser 
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I have created a short proposal to introduce syntactic sugar for
>>>> anonymous functions in a 'scala-like' manner, linked here
>>>> https://github.com/andykais/proposal-placeholder-syntax.
>>>>
>>>> I am hoping to hear feedback on whether or not this is interesting to
>>>> people, as well as feedback on the proposal itself (e.g. is there a better
>>>> operator to use than ` * `)
>>>> ___
>>>> 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: New Proposal: Placeholder syntax

[Jordan Harband]

It seems like the partial application proposal covers all of the use cases
of yours, at a first glance. What does yours offer that partial application
does not?

On Wed, Nov 28, 2018 at 11:23 AM Andrew Kaiser  wrote:

> Do you see a way these proposals can work together? I believe they are
> solving different needs. Both proposals produce a new anonymous function,
> but partial application deals with currying, while the placeholder proposal
> tries to prevent writing a function at all. I can actually see the two
> working together:
>
> ```js
> const filenames = ['file1.txt', 'file2.txt' 'output.log' ]
> const fileContainsContent = (filename, content) =>
> fs.readFileSync(filename).toString().includes(content)
>
> const fileSearchers = filenames.map(fileContainsContent(*, ?))
> const filesContainingSearch = fileSearchers.filter(searcher =>
> searcher('foobar'))
> ```
>
> This isn't a very useful example, but you can see how the proposals differ
> accomplish different things
>
> On Wed, Nov 28, 2018 at 1:30 PM Jordan Harband  wrote:
>
>> You may be interested in the partial application proposal:
>> https://github.com/tc39/proposal-partial-application
>>
>> On Wed, Nov 28, 2018 at 10:17 AM Andrew Kaiser 
>> wrote:
>>
>>> Hi all,
>>>
>>> I have created a short proposal to introduce syntactic sugar for
>>> anonymous functions in a 'scala-like' manner, linked here
>>> https://github.com/andykais/proposal-placeholder-syntax.
>>>
>>> I am hoping to hear feedback on whether or not this is interesting to
>>> people, as well as feedback on the proposal itself (e.g. is there a better
>>> operator to use than ` * `)
>>> ___
>>> 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: New Proposal: Placeholder syntax

[Andrew Kaiser]

Do you see a way these proposals can work together? I believe they are
solving different needs. Both proposals produce a new anonymous function,
but partial application deals with currying, while the placeholder proposal
tries to prevent writing a function at all. I can actually see the two
working together:

```js
const filenames = ['file1.txt', 'file2.txt' 'output.log' ]
const fileContainsContent = (filename, content) =>
fs.readFileSync(filename).toString().includes(content)

const fileSearchers = filenames.map(fileContainsContent(*, ?))
const filesContainingSearch = fileSearchers.filter(searcher =>
searcher('foobar'))
```

This isn't a very useful example, but you can see how the proposals differ
accomplish different things

On Wed, Nov 28, 2018 at 1:30 PM Jordan Harband  wrote:

> You may be interested in the partial application proposal:
> https://github.com/tc39/proposal-partial-application
>
> On Wed, Nov 28, 2018 at 10:17 AM Andrew Kaiser 
> wrote:
>
>> Hi all,
>>
>> I have created a short proposal to introduce syntactic sugar for
>> anonymous functions in a 'scala-like' manner, linked here
>> https://github.com/andykais/proposal-placeholder-syntax.
>>
>> I am hoping to hear feedback on whether or not this is interesting to
>> people, as well as feedback on the proposal itself (e.g. is there a better
>> operator to use than ` * `)
>> ___
>> 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: New Proposal: Placeholder syntax

[Jordan Harband]

You may be interested in the partial application proposal:
https://github.com/tc39/proposal-partial-application

On Wed, Nov 28, 2018 at 10:17 AM Andrew Kaiser  wrote:

> Hi all,
>
> I have created a short proposal to introduce syntactic sugar for anonymous
> functions in a 'scala-like' manner, linked here
> https://github.com/andykais/proposal-placeholder-syntax.
>
> I am hoping to hear feedback on whether or not this is interesting to
> people, as well as feedback on the proposal itself (e.g. is there a better
> operator to use than ` * `)
> ___
> 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

New Proposal: Placeholder syntax

[Andrew Kaiser]

Hi all,

I have created a short proposal to introduce syntactic sugar for anonymous
functions in a 'scala-like' manner, linked here
https://github.com/andykais/proposal-placeholder-syntax.

I am hoping to hear feedback on whether or not this is interesting to
people, as well as feedback on the proposal itself (e.g. is there a better
operator to use than ` * `)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

New Proposal: Number.range (Yes, range again)

[Jack Works]

Hello everyone.
I've searched for the mailing list, there are some discussions add `new
Range` or `a ... b` into the language but not become a formal proposal.

I've made a full demo(polyfill) these days. Anyone interested?

Preview: `for (let i of Number.range(1, 5)) console.log(i)`

And there is an extended version that let range support number range check
`if ( x in Number.range(0, 100) )`.
About usage, test case, and demo of the extended version is posted on gist.

https://gist.github.com/Jack-Works/aa8d4c5dbd0e8cdd415783de8d922451

(
This proposal can also/or add an new operator instead.
`Number.range(x, y)` => `x...y`
`Number.range(x, y, z)` => `(x...y).step(z)` or `x...z->y` or something
else, and other behavior keep same with the Number.range implmentation in
the gist
)

Here is the base version of the proposal
```js
Number.range = function*(from, to, step) {
if (
typeof from !== 'number' &&
typeof from !== 'bigint' &&
(typeof to !== 'number' && typeof to !== 'bigint') &&
(typeof step !== 'number' && typeof step !== 'bigint' && typeof
step !== 'undefined')
)
throw new TypeError('All parameters must be a number or a BigInt')

if (typeof from === 'bigint' && typeof step === 'undefined') step = 1n
else if (typeof from === 'number' && typeof step === 'undefined') step
= 1

if (typeof from !== typeof to || typeof from !== typeof step) throw new
TypeError('Type of all parameters must be the same')
if (typeof from === "number" && Number.isNaN(from) || Number.isNaN(to)
|| Number.isNaN(step)) return;
// Quit early with no value yield

// Math.abs does not support BigInt.
const abs = x => (x >= (typeof x === 'bigint' ? 0n : 0) ? x : -x)

const increase = to > from
// Ignore the symbol
if (increase) step = abs(step)
else step = -abs(step)

let count = typeof from === 'bigint' ? 1n : 1
let now = from
while (increase ? !(now >= to) : !(to >= now)) {
yield now
now = from + step * count
count++
}
}
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: New: proposal-safe-prototype

[Ranando King]

Ok. I just updated the proposal.
Since T.J. felt so strongly about the use of the word "template", I removed
it from the proposal. No need to raise unnecessary ire.
Since using `new` to trigger the behavior is a no-go just like pragmas, I
introduced 2 new well known Symbols.
* `Symbol.SafeProto = Symbol("SafeProto")` to mark objects that should
exhibit the new behavior.
* `Symbol.UnsafeProto = Symbol("UnsafeProto")` to mark objects that **must
not** exhibit the new behavior.

On Tue, Nov 27, 2018 at 1:13 PM Jordan Harband  wrote:

> Correct, existing code *used with* existing code can't break. It's totally
> fine for existing code that works with objects produced by new code to
> break.
>
> On Tue, Nov 27, 2018 at 11:05 AM Ranando King  wrote:
>
>> Is this to say that no new feature is allowed to introduce breaking
>> changes in existing code?
>>
>> On Tue, Nov 27, 2018 at 1:00 PM Jordan Harband  wrote:
>>
>>> What I meant by "preserve existing behavior" is that *all current code*
>>> must retain the footgun. Any chance must only apply to new code that
>>> explicitly opts in to it.
>>>
>>> On Tue, Nov 27, 2018 at 10:55 AM Ranando King  wrote:
>>>
>>>> > Not something you'd want to do often...
>>>>
>>>> Or ever. This is the foot-gun behavior. The same result can be achieved
>>>> with a simple factory class.
>>>> ```js
>>>> class Example {
>>>>   //Don't use "this". It was flagged to use the updated prototype
>>>> behavior.
>>>>   return Object.create(Example.prototype);
>>>> }
>>>> Example.prototype.sharedObject = {
>>>> counter: 0
>>>> };
>>>> const e1 = new Example();
>>>> const e2 = new Example();
>>>> console.log(e2.sharedObject.counter); // 0
>>>> ++e1.sharedObject.counter;
>>>> console.log(e2.sharedObject.counter); // 1
>>>> ```
>>>> This is what I meant when I said that the existing behavior isn't lost.
>>>> There are still plenty of ways to achieve the foot-gun behavior if that is
>>>> what's desired. What this proposal seeks is a means of making the most
>>>> common path foot-gun free.
>>>>
>>>> Besides, a cleaner result can be achieved by using a static property.
>>>> ```js
>>>> class Example {
>>>> }
>>>> Example.counter = 0;
>>>>
>>>> const e1 = new Example();
>>>> const e2 = new Example();
>>>> console.log(e2.constructor.counter); // 0
>>>> ++e1.constructor.counter;
>>>> console.log(e2.constructor.counter); // 1
>>>> ```
>>>>
>>>>
>>>> On Tue, Nov 27, 2018 at 10:30 AM T.J. Crowder <
>>>> tj.crow...@farsightsoftware.com> wrote:
>>>>
>>>>> On Tue, Nov 27, 2018 at 3:34 PM Ranando King
>>>>>  wrote:
>>>>> > The fact that the prototype is a 1st class, (usually) mutable
>>>>> > object doesn't change the fact that it is a template.
>>>>>
>>>>> It fundamentally does, calling prototypes templates rather
>>>>> short-changes them. Again, they're live objects:
>>>>>
>>>>> ```js
>>>>> class Example {
>>>>> }
>>>>> const e = new Example();
>>>>> console.log(e.foo); // undefined
>>>>> Example.prototype.foo = "bar";
>>>>> console.log(e.foo); // "bar"
>>>>> ```
>>>>>
>>>>> (http://jsfiddle.net/pot8cdq6/) A *template* wouldn't demonstrate
>>>>> that sort of behavior. Perhaps it's just a semantic point, though.
>>>>>
>>>>> > As for changing `new` in an incompatible way, doesn't represent a
>>>>> > significant or incompatible change in the behavior of `new`.
>>>>>
>>>>> Of course it does. If it didn't, it wouldn't solve the problem you
>>>>> describe wanting to solve. Or was there some opt-in (other than the 
>>>>> pragma)
>>>>> that I missed? The problem you describe is perfectly valid current code:
>>>>>
>>>>> ```js
>>>>> class Example {
>>>>> }
>>>>> Example.prototype.sharedObject = {
>>>>> counter: 0
>>>>> };
>>>>> const e1 = new Example();
>>&g

Re: New: proposal-safe-prototype

[Jordan Harband]

Correct, existing code *used with* existing code can't break. It's totally
fine for existing code that works with objects produced by new code to
break.

On Tue, Nov 27, 2018 at 11:05 AM Ranando King  wrote:

> Is this to say that no new feature is allowed to introduce breaking
> changes in existing code?
>
> On Tue, Nov 27, 2018 at 1:00 PM Jordan Harband  wrote:
>
>> What I meant by "preserve existing behavior" is that *all current code*
>> must retain the footgun. Any chance must only apply to new code that
>> explicitly opts in to it.
>>
>> On Tue, Nov 27, 2018 at 10:55 AM Ranando King  wrote:
>>
>>> > Not something you'd want to do often...
>>>
>>> Or ever. This is the foot-gun behavior. The same result can be achieved
>>> with a simple factory class.
>>> ```js
>>> class Example {
>>>   //Don't use "this". It was flagged to use the updated prototype
>>> behavior.
>>>   return Object.create(Example.prototype);
>>> }
>>> Example.prototype.sharedObject = {
>>> counter: 0
>>> };
>>> const e1 = new Example();
>>> const e2 = new Example();
>>> console.log(e2.sharedObject.counter); // 0
>>> ++e1.sharedObject.counter;
>>> console.log(e2.sharedObject.counter); // 1
>>> ```
>>> This is what I meant when I said that the existing behavior isn't lost.
>>> There are still plenty of ways to achieve the foot-gun behavior if that is
>>> what's desired. What this proposal seeks is a means of making the most
>>> common path foot-gun free.
>>>
>>> Besides, a cleaner result can be achieved by using a static property.
>>> ```js
>>> class Example {
>>> }
>>> Example.counter = 0;
>>>
>>> const e1 = new Example();
>>> const e2 = new Example();
>>> console.log(e2.constructor.counter); // 0
>>> ++e1.constructor.counter;
>>> console.log(e2.constructor.counter); // 1
>>> ```
>>>
>>>
>>> On Tue, Nov 27, 2018 at 10:30 AM T.J. Crowder <
>>> tj.crow...@farsightsoftware.com> wrote:
>>>
>>>> On Tue, Nov 27, 2018 at 3:34 PM Ranando King
>>>>  wrote:
>>>> > The fact that the prototype is a 1st class, (usually) mutable
>>>> > object doesn't change the fact that it is a template.
>>>>
>>>> It fundamentally does, calling prototypes templates rather
>>>> short-changes them. Again, they're live objects:
>>>>
>>>> ```js
>>>> class Example {
>>>> }
>>>> const e = new Example();
>>>> console.log(e.foo); // undefined
>>>> Example.prototype.foo = "bar";
>>>> console.log(e.foo); // "bar"
>>>> ```
>>>>
>>>> (http://jsfiddle.net/pot8cdq6/) A *template* wouldn't demonstrate that
>>>> sort of behavior. Perhaps it's just a semantic point, though.
>>>>
>>>> > As for changing `new` in an incompatible way, doesn't represent a
>>>> > significant or incompatible change in the behavior of `new`.
>>>>
>>>> Of course it does. If it didn't, it wouldn't solve the problem you
>>>> describe wanting to solve. Or was there some opt-in (other than the pragma)
>>>> that I missed? The problem you describe is perfectly valid current code:
>>>>
>>>> ```js
>>>> class Example {
>>>> }
>>>> Example.prototype.sharedObject = {
>>>> counter: 0
>>>> };
>>>> const e1 = new Example();
>>>> const e2 = new Example();
>>>> console.log(e2.sharedObject.counter); // 0
>>>> ++e1.sharedObject.counter;
>>>> console.log(e2.sharedObject.counter); // 1
>>>> ```
>>>>
>>>> (http://jsfiddle.net/m49jsxof/) Not something you'd want to do often,
>>>> but perfectly valid and I expect there are use cases for it, which changing
>>>> it would break.
>>>>
>>>> Re the rest: Yes, it's complicated to solve for nested properties. But
>>>> again, you just repeat the pattern, and/or use a Proxy; you can certainly
>>>> preserve prototypes as needed. The way in which you do so will vary
>>>> dramatically depending on what your use case is and how much you want to
>>>> copy, etc.
>>>>
>>>> I certainly don't see adding new semantics to `new`. I could see a
>>>> library function setting things up for you, but I think the patterns would
>>>> be so project-specific that it's unlikely to go into the standard library.
>>>>
>>>> I'll step back at this point.
>>>>
>>>> Best,
>>>>
>>>> -- T.J. Crowder
>>>>
>>> ___
>>> 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