Re: Since JSDoc seems cerebrally dead...

[kai zhu]

> Sorry but my question isn't about providing a tool to generate our
documentations but to have a standard syntax to describe our code
(signatures). ;)

not standard-practice, but my style is to have documentation of functions
inside the function (rather than above it).
simplifies doc-generation by calling function's `.toString()` (rather than
having to parse the parse the entire script):

*```js*

































*let html;let local;local = {};local.foo1 = function (aa, bb) {/* * this
function will blah blah blah */return aa + bb;};local.foo2 = function
(cc, dd) {/* * this function will yada yada yada */return cc + dd;};//
auto-generate doc for functions in namespace html =
"\n\n";Object.entries(local).sort().forEach(function ([name,
obj]) {if (typeof obj === "function") {
obj.toString().replace((
/function\b.*?(\([\S\s]*?\))\s*?\{\n?(\s*?\/\*[\S\s]*?\*\/)/),
function (ignore, signature, comment) {html += "function "
+ name + " " + signature.trim() + "\n";html += "\n" +
comment + "\n\n";html += "\n";});}});html +=
"\n";console.log(html);*
*```*

*output*
*```html*

















*function foo1 (aa, bb)/* * this function will blah
blah blah */function foo2 (cc, dd)/* * this function
will yada yada yada */*
*```*


On Wed, Oct 14, 2020 at 5:25 AM Michaël Rouges 
wrote:

> Sorry but my question isn't about providing a tool to generate our
> documentations but to have a standard syntax to describe our code
> (signatures). ;)
>
>
> Michaël Rouges - https://github.com/Lcfvs - @Lcfvs
>
>
> Le mar. 13 oct. 2020 à 01:29, Jordan Harband  a écrit :
>
>> Hopefully (imo) people are hand-writing more docs now, rather than
>> relying on autogenerated prose.
>>
>> On Mon, Oct 12, 2020 at 1:23 PM #!/JoePea  wrote:
>>
>>> Why not? People are generating less docs now? That doesn't sound good!
>>>
>>> #!/JoePea
>>>
>>> On Mon, Aug 17, 2020 at 4:15 PM Isiah Meadows 
>>> wrote:
>>> >
>>> > JSDoc is not dead (far from it), people just don't frequently use
>>> > automated docs generation tooling in the JS community. Most the actual
>>> > use JSDoc provides nowadays is editor autocomplete hints and
>>> > integrating with TypeScript (in cases where changing the extension
>>> > isn't possible for whatever reason), so while it's still useful, it's
>>> > just not used in the same places it was used previously.
>>> >
>>> > -
>>> >
>>> > Isiah Meadows
>>> > cont...@isiahmeadows.com
>>> > www.isiahmeadows.com
>>> >
>>> > On Sun, Aug 16, 2020 at 6:39 PM Michaël Rouges <
>>> michael.rou...@gmail.com> wrote:
>>> > >
>>> > > Hi all,
>>> > >
>>> > > Since JSDoc seems cerebrally dead, why the TC39 doesn't make a real
>>> documentation standard, evolving with the langage?
>>> > >
>>> > > Actually, a part of  the JS community are exiling to TS to type
>>> anything and the rest are just despited by the very outdated version of
>>> JSDoc but don't want to add TS to their stack.
>>> > >
>>> > > IMHO, it's really urgent to have something formal to solve that
>>> missing point of my favorite language.
>>> > >
>>> > > What would it take to make this dream come true, please?
>>> > >
>>> > >
>>> > > Michaël Rouges - https://github.com/Lcfvs - @Lcfvs
>>> > > ___
>>> > > es-discuss mailing list
>>> > > es-discuss@mozilla.org
>>> > > https://mail.mozilla.org/listinfo/es-discuss
>>> > ___
>>> > es-discuss mailing list
>>> > es-discuss@mozilla.org
>>> > https://mail.mozilla.org/listinfo/es-discuss
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Why does a JavaScript class getter for a private field fail using a Proxy?

[kai zhu]

as product-developer, can i ask what ux-objective you ultimately want
achieved?

```js
const sub = new Sub()

// i'm a noob on proxies. what is this thing (with proxied-private-fields)
ultimately used for?
const proxy = new Proxy(sub, ...)
```

On Sun, Jul 12, 2020 at 4:34 PM Michael Theriot <
michael.lee.ther...@gmail.com> wrote:

> This does require you to have both the key and the weakmap though, so it
> actually does succeed in hiding the data so long as the weakmap is out of
> scope. I guess the issue I can foresee is that the key could be modified
> after the object is created.
>
> e.g.
> ```js
> var a = new A();
> var key = Object.getOwnPropertySymbols(a)[0];
> delete a[key];
> a.hidden; // throws
> ```
>
> That itself can be guarded by just making the key undeletable. So, I guess
> this solution could work depending what your goals are?
>
> On Sun, Jul 12, 2020 at 4:21 PM Michael Theriot <
> michael.lee.ther...@gmail.com> wrote:
>
>> It nearly works, but the issue is that the key will be leaked by
>> `Object.getOwnPropertySymbols(new A())`, so it's not truly private.
>>
>> There have been ideas proposing "private symbols" but I am not familiar
>> with their issues, and I would guess with Class Fields they are unlikely to
>> materialize anyway.
>>
>> On Sun, Jul 12, 2020 at 2:19 PM François REMY <
>> francois.remy@outlook.com> wrote:
>>
>>> At the risk of pointing out the obvious:
>>>
>>>
>>>
>>> ```js
>>>
>>> const privkey = Symbol();
>>>
>>> const stores = new WeakMap();
>>>
>>>
>>>
>>> class A {
>>>
>>>   [privkey] = {};
>>>
>>>   constructor() {
>>>
>>> const priv = {};
>>>
>>> priv.hidden = Math.random();
>>>
>>> stores.set(this[privkey], priv);
>>>
>>>   }
>>>
>>>
>>>
>>>   get hidden() {
>>>
>>> const priv = stores.get(this[privkey]);
>>>
>>> return priv.hidden;
>>>
>>>   }
>>>
>>> }
>>>
>>>
>>>
>>> var as = [
>>>
>>> new A(),
>>>
>>> new Proxy(new A(),{}),
>>>
>>> new Proxy(new A(),{}),
>>>
>>> ];
>>>
>>> console.log(as.map(a=>a.hidden));
>>>
>>> ```
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From: *Michael Theriot 
>>> *Sent: *Sunday, July 12, 2020 20:59
>>> *To: *Michael Haufe 
>>> *Cc: *es-discuss@mozilla.org
>>> *Subject: *Re: Why does a JavaScript class getter for a private field
>>> fail using a Proxy?
>>>
>>>
>>>
>>> I experienced this issue prior to this proposal, using weakmaps for
>>> private access.
>>>
>>>
>>>
>>> e.g.
>>>
>>> ```js
>>>
>>> const stores = new WeakMap();
>>>
>>> class A {
>>>   constructor() {
>>> const priv = {};
>>> priv.hidden = 0;
>>> stores.set(this, priv);
>>>   }
>>>
>>>   get hidden() {
>>> const priv = stores.get(this);
>>> return priv.hidden;
>>>   }
>>> }
>>>
>>> const a = new A();
>>> console.log(a.hidden); // 0
>>>
>>> const p = new Proxy(a, {});
>>> console.log(p.hidden); // throws!
>>>
>>> ```
>>>
>>>
>>>
>>> I found a workaround:
>>>
>>>
>>>
>>> ```js
>>> const stores = new WeakMap();
>>>
>>> class A {
>>>   constructor() {
>>> const priv = {};
>>> priv.hidden = 0;
>>> stores.set(this, priv);
>>>
>>> const p = new Proxy(this, {});
>>> stores.set(p, priv); // set proxy to map to the same private store
>>>
>>> return p;
>>>   }
>>>
>>>   get hidden() {
>>> const priv = stores.get(this); // the original instance and proxy
>>> both map to the same private store now
>>> return priv.hidden;
>>>   }
>>> }
>>>
>>> const a = new A();
>>>
>>> console.log(a.hidden);
>>> ```
>>>
>>>
>>>
>>> Not ideal, and only works if you provide the proxy in the first place
>>> (e.g. making exotic JS objects). But, not necessarily a new issue with
>>> proxies, either.
>>>
>>>
>>>
>>> On Fri, Jun 5, 2020 at 12:29 AM Michael Haufe 
>>> wrote:
>>>
>>> This is a known issue and very painful for me as well. You can see a
>>> long ugly discussion here:
>>>
>>>
>>>
>>> 
>>>
>>>
>>>
>>> I suggest the following guide to assist you:
>>>
>>>
>>>
>>> 
>>>
>>>
>>>
>>> Another possible approach is to have your classes extend a proxy:
>>>
>>>
>>>
>>> <
>>> https://github.com/tc39/proposal-class-fields/issues/106#issuecomment-397484713
>>> >
>>>
>>>
>>>
>>>
>>>
>>> *From:* es-discuss  *On Behalf Of *Laurie
>>> Harper
>>> *Sent:* Friday, June 5, 2020 12:21 AM
>>> *To:* es-discuss@mozilla.org
>>> *Subject:* Why does a JavaScript class getter for a private field fail
>>> using a Proxy?
>>>
>>>
>>>
>>> I can expose private class fields in JavaScript using getters, and those
>>> getters work correctly when invoked on instances of a subclass. However, if
>>> I then wrap the instance with a proxy the getter will throw a type error,
>>> even if the proxy `get` hook uses `Reflect.get()`:
>>>
>>> ```
>>> class Base {
>>> _attrA
>>> #_attrB
>>>
>>> constructor() {
>>> this._attrA = 100
>>> this.#_attrB = 200
>>> }
>>>
>>> get A() { return 

Re: Any way to detect an async stack trace (like Chrome devtools does)?

[kai zhu]

>  (I want to detect traces in third-party code installed locally).

1. here's 15-line javascript-hack to trace async-fetch-calls from
3rd-party-cdn-library

```html



test.html

(function () {
/*
 * 15-line-javascript-hack to trace async-fetch-calls
 * enable hack by adding search-query "?modeDebugFetch=1" to web-url
 */
"use strict";
if ((/\bmodeDebugFetch=1\b/).test(location.search)) {
let fetch0;
fetch0 = globalThis.fetch;
globalThis.fetch = function (...argList) {
let errStack = new Error().stack;
console.error("\n\nfetch-call-arguments:");
console.error(JSON.stringify(argList, undefined, 4));
console.error("\n\nfetch-call-trace:");
console.error(errStack);
return fetch0(...argList);
};
}
}());


https://unpkg.com/http-client/umd/http-client.js&quot</a>;>

(async function foo() {
"use strict";
let thirdParty = window.HTTPClient;
let myFetch = thirdParty.createFetch(
thirdParty.base("<a  rel="nofollow" href="https://api.stripe.com/v1&quot">https://api.stripe.com/v1&quot</a>;),
thirdParty.accept("application/json")
);
let response = await myFetch("/customers/5");
console.log(response.jsonData);
/*
dev-console-output - <a  rel="nofollow" href="http://localhost:8081/test.html?modeDebugFetch=1">http://localhost:8081/test.html?modeDebugFetch=1</a>
fetch-call-arguments:
[
"<a  rel="nofollow" href="https://api.stripe.com/v1/customers/5&quot">https://api.stripe.com/v1/customers/5&quot</a>;,
{
"headers": {
"Accept": "application/json"
},
"responseHandlers": [
null
]
}
]
fetch-call-trace:
Error
at globalThis.fetch (test.html?modeDebugFetch=1:16)
at http-client.js:194
at http-client.js:127
at http-client.js:217
at http-client.js:126
at http-client.js:154
at http-client.js:95
at foo (test.html?modeDebugFetch=1:35)
at test.html?modeDebugFetch=1:64
*/
}());


```


2. here's real-world-hack added to npm-cli.js to debug its http-requests

```diff
C:\Program Files\nodejs\node_modules\npm>git diff
diff --git a/bin/npm-cli.js b/bin/npm-cli.js
index 561dec0..98cafb8 100644
--- a/bin/npm-cli.js
+++ b/bin/npm-cli.js
@@ -2,17 +2,6 @@
 ;(function () { // wrapper in case we're in module_context mode
+// hack - debug http-request
+let httpRequest;
+httpRequest = require("https").request.bind(require("https"));
+require("https").request = function (...argList) {
+if (process.env.NPM_DEBUG) {
+console.error(
+"npm - httpRequest - " + JSON.stringify(argList.slice(0, 2),
undefined, 4)
+);
+}
+return httpRequest(...argList);
+};
   // windows: running "npm blah" in this folder will invoke WSH, not node.

C:\Program Files\nodejs\node_modules\npm>
```

```mingw-bash
$ NPM_DEBUG=1 npm publish foo
# console-ouput:
# npm - httpRequest - [
# {
# "protocol": "https:",
# "href": "https://registry.npmjs.org/foo;,
# "method": "GET",
# "headers": {
# "connection": [
# "keep-alive"
# ],
# "user-agent": [
# "npm/6.13.4 node/v12.16.1 win32 x64"
# ],
# ...
```





On Fri, Jul 10, 2020 at 3:34 AM #!/JoePea  wrote:

> Thanks for the idea! That's similar to what I thought would be necessary.
> I was hoping to monkey patch `fetch()` to have it get the trace if any
> `fetch` call, but they would not be async stack traces. For async traces it
> would require instrumentation by injecting code similar to yours (I want to
> detect traces in third-party code installed locally).
>
> #!/JoePea
>
> On Wed, Jul 8, 2020, 2:13 AM kai zhu  wrote:
>
>> here's a simple throwaway-function you can wrap around promises like fetch
>> to get the caller's async-stack-trace `promiseWithErrorStack`:
>>
>> ```html
>> 
>> 
>> 
>> test.html
>> 
>> (async function foo() {
>> function promiseWithErrorStack(promise) {
>> /*
>>  * this function will append current-stack to any err caught from
>> <promise>
>>  */
>> let errStack;
>> errStack = new Error().stack;
>> return new Promise(function (resolve, reject) {
>> promise.then(resolve).catch(function (err) {
>> // append current errStack to err.stack
>> 

Re: Any way to detect an async stack trace (like Chrome devtools does)?

[kai zhu]

here's a simple throwaway-function you can wrap around promises like fetch
to get the caller's async-stack-trace `promiseWithErrorStack`:

```html



test.html

(async function foo() {
function promiseWithErrorStack(promise) {
/*
 * this function will append current-stack to any err caught from

 */
let errStack;
errStack = new Error().stack;
return new Promise(function (resolve, reject) {
promise.then(resolve).catch(function (err) {
// append current errStack to err.stack
if (err && typeof err.stack === "string") {
err.stack += "\n" + errStack;
}
reject(err);
});
});
}
await promiseWithErrorStack(fetch("https://example.com";)); // at foo
(test.html:23)

/*
console-output:

Uncaught (in promise) TypeError: Failed to fetch
Error
at promiseWithErrorStack (test.html:12)
at foo (test.html:23) // async-stack-trace
at test.html:32
*/
}());


```

On Tue, Jul 7, 2020 at 11:54 PM #!/JoePea  wrote:

> Is there some way (perhaps by patching methods on objects?) so we can
> track async call stacks?
>
> When we pause code in devtools, we are able to see the async stack
> trace of the code.
>
> What I'd like to do is to effectively detect the same thing as
> devtools does at some point in any code. As a specific example, I'd
> like to detect the async stack trace of any call to `fetch`.
>
> Is such a thing possible with runtime code?
>
> Or would it require instrumentation of the source code?
>
> #!/JoePea
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Yet another attempt at typed JS data

[kai zhu]

>  And yes, I've used SQLite wasm version too ... as a matter of fact, it's
going to be a great lazy-loaded thing for my next project, 'cause it's 1MB
overhead, so not something to really promote in the wild, imho 

sqlite's homepage claims: "our best guess is that SQLite is the second
mostly widely deployed software library, after libz" [1].  whether true or
not, i think we can agree its an ubiquitous (and hopefully well-understood)
piece of software library.

i know its not a tc39 thing, but perhaps some of its members who are also
implementers would consider making wasm-sqlite3 a 3rd-party browser
"builtin" (like libz/ffmpeg/libpng, but as sandboxed-wasm exposed to
userland) to improve its loading-performance.

-kai

[1] Most Widely Deployed and Used Database Engine
https://www.sqlite.org/mostdeployed.html


On Mon, Feb 10, 2020 at 5:26 PM Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> > Given your history I know better than to assume what you know…
>
> I've no idea what you are talking about, but this should be no venue for
> these kind of answers.
>
> My history in this thread explained the proposal, the intent, and linked
> all the facts around it, and before your pointless answer, so please keep
> your biases for yourself.
>
> Thank you.
>
>
> On Mon, Feb 10, 2020 at 10:13 PM Michael Haufe 
> wrote:
>
>> Given your history I know better than to assume what you know…
>>
>>
>>
>> The definition of sparse in the spec (while not explicitly in its own
>> section) is straightforward.
>>
>>
>>
>> V8’s inability or unwillingness to perform a safe “upcast” internally to
>> an appropriate tag doesn’t seem to provide enough weight to introduce a new
>> construct.
>>
>>
>>
>>
>>
>> *From:* Andrea Giammarchi 
>> *Sent:* Monday, February 10, 2020 2:26 PM
>> *To:* Michael Haufe 
>> *Cc:* Bergi ; es-discuss@mozilla.org
>> *Subject:* Re: Yet another attempt at typed JS data
>>
>>
>>
>> Great, now maybe you also read how it works behind the scene, and debug
>> properly to understand that every array is holey, including the latter one,
>> to date.
>>
>>
>>
>> https://v8.dev/blog/elements-kinds
>>
>>
>>
>> Please, let's assume for a second I knew what I was talking about, when
>> I've said it's a mess to not have holey arrays, thanks.
>>
>>
>>
>> On Mon, Feb 10, 2020 at 9:21 PM Michael Haufe 
>> wrote:
>>
>> Array(3)
>> //  [empty × 3]
>>
>> Array(3).fill()
>> // [undefined, undefined, undefined]
>>
>> Array(3).fill('whatever')
>> // ["whatever", "whatever", "whatever"]
>>
>>
>> -Original Message-
>> From: es-discuss  On Behalf Of Bergi
>> Sent: Monday, February 10, 2020 1:27 PM
>> To: es-discuss@mozilla.org
>> Subject: Re: Yet another attempt at typed JS data
>>
>> Hello!
>>
>> > Unfortunately, `Array.from({ length: 4 }, () => whatever)` produces a
>> > holey array
>>
>> Does it? But really, if the performance difference betweeen HOLEY and
>> PACKED arrays were large enough to be relevant[1], the engine programmers
>> would certainly already have optimised all those trivial cases where an
>> array is filled gradually to produce the more efficient representation.
>>
>> kind regards,
>>  Bergi
>>
>> [1]: it probably isn't:
>> https://stackoverflow.com/questions/54481918/#comment95848513_54485509
>> ___
>> 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: Yet another attempt at typed JS data

[kai zhu]

if you really care about performance AND structured-data, perhaps
javascript is not the best tool for the job.

if you goto the wasm-sqlite3 demo @
https://kaizhu256.github.io/demo-sqljs-csv/
you can paste the following code into browser's dev-console to ingest a
million-row csv and perform queries on it:

```js
(async function () {
"use strict";
let csv;
let ii;
let randomSelect;
let result;
randomSelect = function (list) {
/*
 * this function will select a random element from list
 */
return list[Math.floor(list.length * Math.random())];
};
csv = "rowid,name,address,random\n";
ii = 0;
while (ii < 100) {
csv += (
ii + 1 + ","
+ randomSelect([
"Bob", "Jane", "John"
]) + " " + randomSelect([
"Doe", "Smith", "Williams"
]) + ","
+ "\"1234 Main St., Los Angeles, CA 90001\","
+ Math.random() + "\n"
);
ii += 1;
}
console.error(csv.slice(0, 1000));
// rowid,name,address,random
// 1,Jane Doe,"1234 Main St., Los Angeles, CA 90001",0.8783498663648375
// 2,Bob Williams,"1234 Main St., Los Angeles, CA
90001",0.22973214766766303
// 3,John Doe,"1234 Main St., Los Angeles, CA 90001",0.8658095647533652
// 4,Jane Smith,"1234 Main St., Los Angeles, CA
90001",0.27730496836028085
// ...
// 100,Jane Williams,"1234 Main St., Los Angeles, CA
90001",0.43105992922801883
await window.sqljsTableImport({
csv,
tableName: "table1"
});
// sqljsTableImport - 945 ms - inserted 12,572 rows - 1 MB
// sqljsTableImport - 1163 ms - inserted 25,017 rows - 2 MB
// ...
// sqljsTableImport - 6242 ms - inserted 997,423 rows - 81 MB
// sqljsTableImport - 6252 ms - inserted 1,000,000 rows - 81 MB
result = await window.sqljsExec(
"SELECT * FROM table1 WHERE\n"
+ "name LIKE 'John'\n"
+ "AND random > 0.5\n"
+ "ORDER BY random DESC\n"
+ "LIMIT 1000;"
);
console.error(result.results[0].values);
// ["961621", "John Doe", "1234 Main St., Los Angeles, CA 90001",
"0.999 ...
// ["51800", "John  Williams  ", "1234 Main St., Los Angeles, CA
90001", "0.999 ...
// ["241184", "John  Smith  ", "1234 Main St., Los Angeles, CA 90001",
"0.999 ...
// ["591592", "John  Williams  ", "1234 Main St., Los Angeles, CA
90001", "0.999 ...
// ["32403", "John Doe", "1234 Main St., Los Angeles, CA 90001", "0.999
...
// ["847237", "John  Smith  ", "1234 Main St., Los Angeles, CA 90001",
"0.999 ...
// ["23195", "John Doe", "1234 Main St., Los Angeles, CA 90001", "0.999
...
// ["136423", "John  Smith  ", "1234 Main St., Los Angeles, CA 90001",
"0.999 ...
}());
```
-kai

On Mon, Feb 10, 2020 at 3:08 AM Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> Unfortunately, `Array.from({ length: 4 }, () => whatever)` produces a
> holey array, so that the `.repeat(...)` idea, if capable of packing
> elements in a better way, wouldn't be so terrible, as simplification.
>
> Although, the intent of this proposal was to also grant "shapes" or
> kindness of each entry, same way typed Arrays do, but maybe that would
> require some better primitive, as in `const Shape =
> Object.defineShape(...)` and `Object.createShape(Shape)` or similar.
>
> On Sun, Feb 9, 2020 at 10:01 PM Jordan Harband  wrote:
>
>> That already exists - `Array.from({ length: 4 }, () => whatever)` - I
>> assume that the hope is to have an array where it is *impossible* for it to
>> have the wrong "kind" of data, and a userland factory function wouldn't
>> provide that.
>>
>> On Sun, Feb 9, 2020 at 10:39 AM kai zhu  wrote:
>>
>>> > It's a bit of a mess to create an Array that is not holed and gets
>>> best optimizations [1], and this proposal would like to address that exact
>>> case.
>>>
>>> could the performance issue be resolved more easily with a simple
>>> static-function `Array.repeat(, )`?
>>>
>>> ```js
>>> let structuredList;
>>> structuredList = Array.repeat(4, function (ii) {
>>> return {
>>> index: 2 * ii + 1,
>>> tags: []
>>> });
>>> /*
>>> structured

Re: Yet another attempt at typed JS data

[kai zhu]

> It's a bit of a mess to create an Array that is not holed and gets best
optimizations [1], and this proposal would like to address that exact case.

could the performance issue be resolved more easily with a simple
static-function `Array.repeat(, )`?

```js
let structuredList;
structuredList = Array.repeat(4, function (ii) {
return {
index: 2 * ii + 1,
tags: []
});
/*
structuredList = [
{ index: 1, tags: [] },
{ index: 3, tags: [] },
{ index: 5, tags: [] },
{ index: 7, tags: [] }
];
 */
```

the only time i can practically enforce the shape of a "StructuredArray" is
during element-insertion,
and a userland insertion/creation function would be just as effective as a
StructuredArray constructor.

enforcing shapes during element deletions and updates are going to be hard
and likely just as confusing with StructuredArray as they are with regular
Array.

also note that most javascript arrays need to be easily JSON-serialized for
message-passing
over-the-wire (commonly http) to external systems.

-kai

On Sat, Feb 8, 2020 at 3:46 AM Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> > having to retroactively add checks like...
>
> we already have typed arrays in JS so I don't think this would be any
> different
>
> > I _think_ that moderns virtual machines already did these optimisations
> despite there isn't a TypedArray like that.
>
> It's a bit of a mess to create an Array that is not holed and gets best
> optimizations [1], and this proposal would like to address that exact case.
>
> [1] https://v8.dev/blog/elements-kinds
>
>
>
>
> ___
> 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: One-shot Delimited Continuations with Effect Handlers

[kai zhu]

the usage-scenario is not compelling.
the same effect can be achieved in 12-lines of throwaway-code (i copy
pasted into console), with less tech-debt:

$ node -e '
var nameList = [null, "Gendry"];
nameList.forEach(async function (name) {
// if name is null, then wait 1000ms, and default to "Arya Stark"
if (name === null) {
await new Promise(function (resolve) {
setTimeout(resolve, 1000);
});
name = "Arya Stark";
}
var nameUpperCase = name.toUpperCase();
console.log(nameUpperCase);
});
'
$ GENDRY
$ ARYA STARK



On Tue, Dec 24, 2019 at 4:41 AM Bruno Macabeus 
wrote:

> Hello for all,
>
> I know that this discuss is a little old, but I just found it now and I
> think that it is still useful at this moment.
>
> So I created a very simple Babel plugin to taste and validate the
> Sebatian's idea: https://github.com/macabeus/js-proposal-algebraic-effects
> Maybe it could be useful to test how much this proposal could be useful
> for our JS code.
>
> Algebraic Effects/One-shot delimited continuations/effect handlers are
> viable proposals?
>
> 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: Optional Curly Braces in JavaScript

[kai zhu]

> Python is so broadly used in those fields due to good library support

javascript in modern browsers has good builtin-api support for most
ux-scenarios you can think of. the only thing really missing (and which
python has) is a builtin wasm-sqlite3 library (and specialized/secure
file-api's to persist sqlite-db-blobs).

then the remaining hard ux-problems like
shopping-carts/typeahead-fts-search/million-row-datatables/etc would no
longer be hard -- and can even be implemented w/o need of a backend, making
"serverless" frontend-apps truly serverless.

On Sun, Nov 3, 2019, 11:52 Sanford Whiteman <
swhitemanlistens-softw...@figureone.com> wrote:

> > I don't see any reason why Python is widely used in math and
> > science…
>
> Should talk to longtime Python peeps about it, it's not just "easy" or
> they'd be using VB6!
>
> Let me leave this here:
>
> Python has had bignum (arbitrary precision Integers) since 2008.
> Even before that, it had Long (not just Double).
>
> V8 (used as a reference for non-browser development) has had
> BigInt since... 2018.
>
> — S.
>
>
>
>
> ___
> 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: Optional Curly Braces in JavaScript

[kai zhu]

unlike python, many [client-side] javascript programs require
rollup/minification into a single dist-file.  removing curly braces (just
like asi) makes that task more difficult.

this is also why esm-import-statements were a terrible idea. ppl like me
would argue frontend-programs (which are mostly non-reusable anyways)
should be written as single dist-files from the start rather than as
modules -- and why python-programmers make terrible [frontend/ux]
javascript-programmers in general.


On Sun, Nov 3, 2019, 04:48 Jordan Harband  wrote:

> My preference would be to make them required in the places they're
> currently optional :-)
>
> Optional curly braces have led to many bugs, not just in JS (the "goto
> fail" SSL bug, for example) - why is this risk worth making it easier to
> write code on a whiteboard, where it doesn't need to be valid anyways?
>
> On Sat, Nov 2, 2019 at 12:39 PM Bergi  wrote:
>
>> Hello Ed!
>>
>> > That would make JavaScript an easy to write on board language, where a
>> language like python dominates because of it's simplicity in writing. This
>> would make JavaScript spread into more areas in science, education and
>> engineering.
>>
>> You seem to not only want to make block syntax optional, but rather make
>> whitespace indentation significant. You might want to have a look at
>> CoffeeScript  which is a
>> compile-to-JS language that uses this concept. Its function syntax is a
>> bit different from what you imagined though, most importantly it doesn't
>> offer any declarations.
>>
>> 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
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: why is regexp /\-/u a syntax-error?

[kai zhu]

fyi, googling "tc39 regexp unicode" led to web-compat reasoning (learned
something new) @
https://github.com/tc39/proposal-regexp-unicode-property-escapes#what-about-backwards-compatibility

What about backwards compatibility?
In regular expressions without the u flag, the pattern \p is an
(unnecessary) escape sequence for p. Patterns of the form \p{Letter} might
already be present in existing regular expressions without the u flag, and
therefore we cannot assign new meaning to such patterns without breaking
backwards compatibility.

For this reason, ECMAScript 2015 made unnecessary escape sequences like \p
and \P throw an exception when the u flag is set. This enables us to change
the meaning of \p{…} and \P{…} in regular expressions with the u flag
without breaking backwards compatibility.



On Fri, Sep 20, 2019 at 9:13 AM Mathias Bynens  wrote:

> Think of the `u` flag as a strict mode for regular expressions.
>
> `/\a/u` throws, because there is no reason to escape `a` as `\a` --
> therefore, if such an escape sequence is present, it's likely a user error.
> The same goes for `/\-/u`. `-` only has special meaning within character
> classes, not outside of them.
>
> On Fri, Sep 20, 2019 at 11:22 AM kai zhu  wrote:
>
>> jslint previously warned against unescaped literal "-" in regexp.
>>
>> however, escaping "-" together with unicode flag "u", causes syntax error
>> in chrome/firefox/edge (and jslint has since removed warning):
>>
>> ```javascript
>> let rgx = /\-/u
>> VM21:1 Uncaught SyntaxError: Invalid regular expression: /\-/: Invalid
>> escape
>> at :1:10
>> ```
>>
>> just, curious on reason why above edge-case is a syntax-error?
>> ___
>> 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

why is regexp /\-/u a syntax-error?

[kai zhu]

jslint previously warned against unescaped literal "-" in regexp.

however, escaping "-" together with unicode flag "u", causes syntax error
in chrome/firefox/edge (and jslint has since removed warning):

```javascript
let rgx = /\-/u
VM21:1 Uncaught SyntaxError: Invalid regular expression: /\-/: Invalid
escape
at :1:10
```

just, curious on reason why above edge-case is a syntax-error?
___
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

persisting large wasm-sqlite3 datasets in browser (beyond kv-storage)

[kai zhu]

at work, we have browser-app that load-and-persist ~100MB (500k rows)
csv-files into wasm-sqlite3 [1], (ingestion-time is ~15s for 100MB csv).
we wish to go bigger, but chrome's indexeddb has a hard-limit of 125MB per
key-value object (on windows).

i don't have anything actionable.  just want people aware of datapoint, and
think about javascript-language-design to improve UX-handling with
sqlite3-persistence.

fyi, ignoring persistence, chrome can handle wasm-sqlite3 datasets as large
as 300MB (1.5 million rows) in memory, before crashing (on 8gb windows10
machine).

[1] sql.js wasm-sqlite3
https://github.com/kripken/sql.js
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

globalThis.assertOrThrow

[kai zhu]

having a universal assert function (similar to nodejs' assert builtin)
might be useful.  it could be name "assertOrThrow" for web-compat.

this would simplify writing common-case "throwaway" error-handling behavior
in both browsers and nodejs:

```js
// naive polyfill
globalThis.assertOrThrow = globalThis.assertOrThrow || function (passed,
message) {
/*
 * this function will throw error  if  is falsy
 */
if (passed) {
return;
}
throw (
typeof message === "object" && message
? message
: new Error(message)
}
};

localforage.setItem("foo", "bar", function (err, data) {
// validate no err occurred
// this one-line statement makes writing test-coverage less tedious
assertOrThrow(!err, err);
...
});
```

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

Re: Async Class

[kai zhu]

class-factories are good enough. as real-world example, google-puppeteer
uses class-factories to promisify its constructors, which are
easy-to-reason.

if the below Browser/Page classes were also "async", it would be difficult
to
debug their intent in real-world code -- are their instances supposed to act
as promises or as data-objects? i imagine code-maintennance would be a
nightmare.



```js
// "await" puppeteer's Browser constructor
// https://github.com/GoogleChrome/puppeteer/blob/v1.19.0/lib/Browser.js#L23
class Browser extends EventEmitter {
constructor(connection, contextIds, ...) {
...
}
static async create(connection, contextIds, ...) {
const browser = new Browser(connection, contextIds, ...);
await connection.send(...);
return browser;
}
}
//
https://github.com/GoogleChrome/puppeteer/blob/v1.19.0/lib/Launcher.js#L184
const browser = await Browser.create(connection, [], ...);



// "await" puppeteer's Page constructor
// https://github.com/GoogleChrome/puppeteer/blob/v1.19.0/lib/Page.js#L36
class Page extends EventEmitter {
constructor(client, target, ...) {
...
}
static async create(client, target, ...) {
const page = new Page(client, target, ...);
await page._initialize();
...
return page;
}
}
//
https://github.com/kaizhu256/puppeteer-to-istanbul-example/blob/6b3f599f/screenshot.js#L317
page1 = await module.exports.Page.create(null, tmp);
```




On Tue, Aug 27, 2019 at 11:36 AM Claude Pache 
wrote:

>
>
> Le 26 août 2019 à 17:11, Dimitrian Nine  a
> écrit :
>
> Class is just function constructor that return object
>
>
> Although in JS a class is represented by the same object as its
> constructor, I don’t think it is good to assimilate the concept of JS class
> and JS constructor. Indeed, a class consists not only of its constructor,
> but also of all its associated methods. This is what is suggested by the
> syntax:
>
> ```js
> class C {
> /* definition of all methods, not only constructor */
> }
> ```
>
> From that perspective, I understand very well what would be an “async
> constructor”; but an “async class” doesn’t make much sense.
>
> —Claude
> ___
> 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: effect of editor/ide on javascript programming-style

[kai zhu]

vim is arguably the best tool for editing large, self-contained, "rollup"
files like bootstrap.css, jquery.datatables.js, highcharts.js, jslint.js,
etc.  it (and emacs) are the few mainstream editors i'm aware of with
search-as-you-type and bookmark-location functionalities, enabling
sub-second traversal of large text-files.

having 1-5 js-devs develop a web-product consisting of a dozen,
self-contained, "rollup" css/js files is generally more cost-effective than
having 20+ js-devs working on a hundred, fragmented css/js files. in the
former there's:
1. less loss of critical-knowledge about file/module-dependencies and
transpiling/tooling-config-settings when team-members leave the project
2. less siloing/loss-of-big-picture, where you end up micromanaging
"general-purpose" code rather than the UX-workflow code
3. reduced painpoint of operational-deployment, since much of the
"webpacking" is already baked

/* off-topic */
also, in the unlikely scenario a product evolves to legitimately require
20+ js-devs, it would have developed custom, in-house tooling/frameworks
along the way.  a logical-step for many companies is to market their
in-house tooling as "general-purpose" tooling for javascript
product-development.  some of these tools do meet the small-scope,
general-purpose needs of typical 1-5 js-dev web-projects (e.g.
twitter-bootstrap), but most are over-scoped and terribly cost-ineffective.



On Sat, Jun 29, 2019 at 9:10 AM Felipe Nascimento de Moura <
felipenmo...@gmail.com> wrote:

> Really?! That actually surprises me!
>
> I haven't used vim to develop for quite a while, but always saw it as a
> reference in performance.
>
> For instance, I'm right now with 5 different VSCode windows opened (each
> one with a different workspace, for each project I'm currently working on),
> and each of those windows have around 20+ opened tabs. I also like
> splitting the screen of some of those windows in 4 depending on the
> project. I see no problem at all either opening a new file, nor switching
> between them.
>
> I see some lagging, though, when I open a huge json file, or a csv file
> that is too long. That's actually why I like keeping files small.
>
> I'm saying this because you feel like these experiences could change the
> developer behaviour. Made me think how my behaviour actually changed to
> USING multiple smaller files instead of bigger ones.
>
> [ ]s
>
> *--*
>
> *Felipe N. Moura*
> Web Developer, Google Developer Expert
> <https://developers.google.com/experts/people/felipe-moura>, Founder of
> BrazilJS <https://braziljs.org/> and Nasc <http://nasc.io/>.
>
> Website:  http://felipenmoura.com / http://nasc.io/
> Twitter:@felipenmoura <http://twitter.com/felipenmoura>
> Facebook: http://fb.com/felipenmoura
> LinkedIn: http://goo.gl/qGmq
> -
> *Changing  the  world*  is the least I expect from  myself!
>
>
> On Fri, Jun 28, 2019 at 4:03 PM kai zhu  wrote:
>
>> i agree vim is efficient for switching between existing files/buffers.
>> but *opening* new files is a PITA, which subtly affects
>> programming-behavior of its users -- towards javascript-programming tending
>> less towards fragmenting code with multiple files/modules (and more towards
>> code-locality).
>>
>> on customizing vim, i think its more productive that you get used to
>> editing with default settings.  it certainly helps in (unix/mac)
>> coding-interviews and troubleshooting production-machines, where the only
>> guaranteed editor is [an uncustomized] vim.
>>
>> On Fri, Jun 28, 2019 at 1:49 PM Andy Earnshaw 
>> wrote:
>>
>>> I would agree for Vim in its basic form but have successfully used vim,
>>> for several years, with the Ctrl+P extension to quickly and efficiently get
>>> around codebases with many files. It also has a buffer lookup for accessing
>>> already open files, and other shortcuts like Ctrl+B/Ctrl+6 make switching
>>> between 2 files for simultaneous editing a breeze, which I found invaluable
>>> for writing tests alongside the main code.
>>>
>>> Vim gets more productive the more you customise it, but that makes it
>>> harder to use when you're on a different machine without those
>>> customisations. Still, most of the time you'll take your config with you. I
>>> would say that if you feel inefficient at doing something in Vim then it's
>>> something you can work on.
>>>
>>> On Fri, 28 Jun 2019, 19:30 kai zhu,  wrote:
>>>
>>>> 3 frontend-devs is reasonable and maybe ideal -- but reality is most
>>>> shops can only afford 1 frontend-dev.  i re

Re: effect of editor/ide on javascript programming-style

[kai zhu]

i agree vim is efficient for switching between existing files/buffers.  but
*opening* new files is a PITA, which subtly affects programming-behavior of
its users -- towards javascript-programming tending less towards
fragmenting code with multiple files/modules (and more towards
code-locality).

on customizing vim, i think its more productive that you get used to
editing with default settings.  it certainly helps in (unix/mac)
coding-interviews and troubleshooting production-machines, where the only
guaranteed editor is [an uncustomized] vim.

On Fri, Jun 28, 2019 at 1:49 PM Andy Earnshaw 
wrote:

> I would agree for Vim in its basic form but have successfully used vim,
> for several years, with the Ctrl+P extension to quickly and efficiently get
> around codebases with many files. It also has a buffer lookup for accessing
> already open files, and other shortcuts like Ctrl+B/Ctrl+6 make switching
> between 2 files for simultaneous editing a breeze, which I found invaluable
> for writing tests alongside the main code.
>
> Vim gets more productive the more you customise it, but that makes it
> harder to use when you're on a different machine without those
> customisations. Still, most of the time you'll take your config with you. I
> would say that if you feel inefficient at doing something in Vim then it's
> something you can work on.
>
> On Fri, 28 Jun 2019, 19:30 kai zhu,  wrote:
>
>> 3 frontend-devs is reasonable and maybe ideal -- but reality is most
>> shops can only afford 1 frontend-dev.  i remain convinced 5 js-devs is
>> around the practical limit for most products.  going over that
>> magic-number, and people become confused about their
>> areas-of-responsibility -- allowing mediocrity/siloing to flourish from
>> lack of accountability.
>>
>> "scalable" javascript tooling/frameworks that allow large-scale
>> collaboration are solutions-in-search-of-a-problem.  they should remain as
>> in-house solutions for the unique problems faced by
>> google/facebook/salesforce/etc, and are inappropriate/overengineered for
>> general-purpose product-development.
>>
>> On Fri, Jun 28, 2019 at 12:58 PM Jordan Harband  wrote:
>>
>>> As much as I like vim, this seems like more of an argument against using
>>> vim than anything for the language - also it's not "usually" just 1
>>> frontend developer; altho that may be your experience. I often like to say
>>> it's *never* just one - even if it's you, it's also "you in 6 months", and
>>> that person is really annoyed with you.
>>>
>>> As an anecdotal data point, my garage startup which had no funding had 3
>>> JS devs working on our frontend. I would argue it's not very cost effective
>>> to *under*invest in frontend dev, but obviously everyone has different
>>> opinions on that - and it's not relevant to this discussion list.
>>>
>>> On Fri, Jun 28, 2019 at 9:59 AM kai zhu  wrote:
>>>
>>>> adding a datapoint on effects of vim-editor on my javascript
>>>> coding-style.  this is to expand on discussion of "JavaScript and Syntax
>>>> Research Methods" in tc39-notes [1].
>>>>
>>>> vim has the following file-editing properties:
>>>> 1. poor UX in opening new files
>>>> 2. efficient content-search/jump/traversal of large files
>>>> 3. can display the same file in multiple editing-windows
>>>>
>>>> because of above properties, i default to writing javascript
>>>> applications as a single, large file (which may get broken up if it becomes
>>>> "too" large, e.g. >10k sloc).  developing javascript-apps with a single
>>>> js-file leads me to:
>>>> 1. prefer reusing external-code by copy/pasting it into single-file
>>>> rather than load it as commonjs/es-module
>>>> 2. be selective about what external-code i want to copy/paste --
>>>> generally only self-contained or "rolled-up" ones w/ minimal
>>>> external-dependencies
>>>> 3. general preference to write self-contained code that easy-to-reuse
>>>> by copy/pasting into a new project [2].
>>>>
>>>> an argument against writing javascript-applications as a single,
>>>> self-contained file, is that it leads to merge/commit conflicts when
>>>> multiple devs are working on same file.  its valid ... except most
>>>> javascript-products are developed by just 1-3 js-devs.  for the frontend,
>>>> its usually just 1 developer.  the hype of making javascript "scalable" so
>>>> you can h

Re: effect of editor/ide on javascript programming-style

[kai zhu]

3 frontend-devs is reasonable and maybe ideal -- but reality is most shops
can only afford 1 frontend-dev.  i remain convinced 5 js-devs is around the
practical limit for most products.  going over that magic-number, and
people become confused about their areas-of-responsibility -- allowing
mediocrity/siloing to flourish from lack of accountability.

"scalable" javascript tooling/frameworks that allow large-scale
collaboration are solutions-in-search-of-a-problem.  they should remain as
in-house solutions for the unique problems faced by
google/facebook/salesforce/etc, and are inappropriate/overengineered for
general-purpose product-development.

On Fri, Jun 28, 2019 at 12:58 PM Jordan Harband  wrote:

> As much as I like vim, this seems like more of an argument against using
> vim than anything for the language - also it's not "usually" just 1
> frontend developer; altho that may be your experience. I often like to say
> it's *never* just one - even if it's you, it's also "you in 6 months", and
> that person is really annoyed with you.
>
> As an anecdotal data point, my garage startup which had no funding had 3
> JS devs working on our frontend. I would argue it's not very cost effective
> to *under*invest in frontend dev, but obviously everyone has different
> opinions on that - and it's not relevant to this discussion list.
>
> On Fri, Jun 28, 2019 at 9:59 AM kai zhu  wrote:
>
>> adding a datapoint on effects of vim-editor on my javascript
>> coding-style.  this is to expand on discussion of "JavaScript and Syntax
>> Research Methods" in tc39-notes [1].
>>
>> vim has the following file-editing properties:
>> 1. poor UX in opening new files
>> 2. efficient content-search/jump/traversal of large files
>> 3. can display the same file in multiple editing-windows
>>
>> because of above properties, i default to writing javascript applications
>> as a single, large file (which may get broken up if it becomes "too" large,
>> e.g. >10k sloc).  developing javascript-apps with a single js-file leads me
>> to:
>> 1. prefer reusing external-code by copy/pasting it into single-file
>> rather than load it as commonjs/es-module
>> 2. be selective about what external-code i want to copy/paste --
>> generally only self-contained or "rolled-up" ones w/ minimal
>> external-dependencies
>> 3. general preference to write self-contained code that easy-to-reuse by
>> copy/pasting into a new project [2].
>>
>> an argument against writing javascript-applications as a single,
>> self-contained file, is that it leads to merge/commit conflicts when
>> multiple devs are working on same file.  its valid ... except most
>> javascript-products are developed by just 1-3 js-devs.  for the frontend,
>> its usually just 1 developer.  the hype of making javascript "scalable" so
>> you can have 20x people working on a product is just that -- hype.  there
>> are very few real-world products where its cost-effective to have more than
>> 5 js-devs working on it.
>>
>> [1] JavaScript and Syntax Research Methods
>>
>> https://github.com/rwaldron/tc39-notes/blob/7a4af23d/meetings/2019-06/june-6.md#javascript-and-syntax-research-methods
>>
>> [2] documentation of various [minimal-dependency] self-contained
>> functions that can be copy/pasted
>>
>> https://kaizhu256.github.io/node-utility2/build..beta..travis-ci.org/apidoc.html
>>
>>
>>
>>
>> screenshot of me vim-editing multiple locations of one, large
>> javascript-file (each sub-window is a different location of the same file).
>> [image: vim-editor-min.png]
>>
>> ___
>> 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

effect of editor/ide on javascript programming-style

[kai zhu]

adding a datapoint on effects of vim-editor on my javascript coding-style.
this is to expand on discussion of "JavaScript and Syntax Research Methods"
in tc39-notes [1].

vim has the following file-editing properties:
1. poor UX in opening new files
2. efficient content-search/jump/traversal of large files
3. can display the same file in multiple editing-windows

because of above properties, i default to writing javascript applications
as a single, large file (which may get broken up if it becomes "too" large,
e.g. >10k sloc).  developing javascript-apps with a single js-file leads me
to:
1. prefer reusing external-code by copy/pasting it into single-file rather
than load it as commonjs/es-module
2. be selective about what external-code i want to copy/paste -- generally
only self-contained or "rolled-up" ones w/ minimal external-dependencies
3. general preference to write self-contained code that easy-to-reuse by
copy/pasting into a new project [2].

an argument against writing javascript-applications as a single,
self-contained file, is that it leads to merge/commit conflicts when
multiple devs are working on same file.  its valid ... except most
javascript-products are developed by just 1-3 js-devs.  for the frontend,
its usually just 1 developer.  the hype of making javascript "scalable" so
you can have 20x people working on a product is just that -- hype.  there
are very few real-world products where its cost-effective to have more than
5 js-devs working on it.

[1] JavaScript and Syntax Research Methods
https://github.com/rwaldron/tc39-notes/blob/7a4af23d/meetings/2019-06/june-6.md#javascript-and-syntax-research-methods

[2] documentation of various [minimal-dependency] self-contained functions
that can be copy/pasted
https://kaizhu256.github.io/node-utility2/build..beta..travis-ci.org/apidoc.html




screenshot of me vim-editing multiple locations of one, large
javascript-file (each sub-window is a different location of the same file).
[image: vim-editor-min.png]
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: `String.prototype.trimStart`/`String.prototype.trimEnd` with a given string

[kai zhu]

fyi, a search of the entire markedjs/marked repo shows 2 places where rtrim
is used:

```js
// https://github.com/markedjs/marked/blob/master/lib/marked.js
227

codeBlockStyle: 'indented',
228

text: !this.options.pedantic
229

? rtrim(cap, '\n')
230

: cap
…
1425

baseUrls[' ' + base] = rtrim(base, '/', true);
1426

}

1427

}

1428

base
= baseUrls[' ' + base];
1429

1430

if (href.slice(0, 2) === '//') {
```

only the 1st use-case does what this thread proposes (the 1st trimRight's
"\n", while the 2nd behaves differently and is more like nodejs'
`require("path").dirname()`

if i were writing the library, i wouldn't have bothered with a
helper-function if its only going to show up in 2 [trivial] places.
would've instead inlined two throwaway regexp-expressions, to keep code
more-self-contained / less-fragmented:

```js
228  text: !this.options.pedantic
229? cap.replace((/\n+$/), "") // remove trailing "\n" or
perhaps just use .trimRight()
230: cap
…
1425  baseUrls[' ' + base] = base.replace((/\/[^\/]*$/), "/"); // get
"dirname" of base-url
1426}
```

On Mon, Jun 24, 2019 at 2:27 PM Jacob Pratt  wrote:

> No idea how common of a use case this is; I personally ran across it when
> reviewing the source code for marked (specifically the [rtrim method]).
> That example only does characters, not strings, but it's used in the wild
> by a package with ~2m weekly downloads on npm.
>
> Of course we wouldn't want `trimStart` to differ from `trimLeft`, they'd
> all be modified in unison. I just think that symmetry between similar
> methods is important, and (apparently) has use cases.
>
> [rtrim method]:
> https://github.com/markedjs/marked/blob/master/lib/marked.js#L1493-L1517
>
> On Mon, Jun 24, 2019 at 12:46 AM Jordan Harband  wrote:
>
>> `trimStart` and `trimEnd` are better-named versions of the very very
>> long-existing `trimLeft` and `trimRight`, which lack this ability, along
>> with ES5's `trim`.
>>
>> It wouldn't make sense for these three to differ.
>>
>> It certainly seems like a potential language proposal to add a string
>> argument to all three; however, at what point is that reimplementing
>> `string.replace(/^(foo)+/, '')`, `string.replace(/(foo)+$/, '')`, and
>> `string.replace(/^(foo)+|$(foo)+$/, '')`? How common is the use case to
>> trim matching substrings off of the ends of a string? (the use cases for
>> padding were quite common)
>>
>> On Sun, Jun 23, 2019 at 12:14 AM Jacob Pratt 
>> wrote:
>>
>>> `String.prototype.padStart` and `String.prototype.padEnd` accept the
>>> string to pad with as their final parameter. Is there any particular reason
>>> `String.prototype.trimStart` and `String.prototype.trimEnd` don't do the
>>> same? It would be nice to have a parallel, such that `'foo'.padEnd(10,
>>> 'bar').trimEnd('bar') === 'foo'`.
>>>
>>> References:
>>> - https://github.com/tc39/proposal-string-pad-start-end
>>> - https://github.com/tc39/proposal-string-left-right-trim
>>>
>>> Jacob Pratt
>>> ___
>>> 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: Exposing native scroll as API

[kai zhu]

the referenced video was entertaining to watch (and i learned new things
about typescript and proxies), but i still don't understand your UX-problem
-- at least enough to know what/how a new standard-api would help.

there's a bunch of canvas-scrolling examples @
https://konvajs.org/docs/sandbox/Canvas_Scrolling.html.  examples #1 and #4
implement native canvas-scrolling, with the latter having less jankiness on
my mobile-chrome.  maybe you're asking for consistent #4 css-behavior
across all mobile-browsers (i have no idea if it works as well in
ios-safari)?  that would be w3c csswg's domain.

also somewhat-related -- chrome is debating an intent-to-implement feature
for scrollTo-behavior for text-fragments.
for example:
`https://www.example.com#targetText=You%20may%20use%20this%20domain`
will scroll to element in www.example.com containing text "You may use this
domain". [1]

[1] Scroll-To-Text using a URL fragment
https://github.com/bokand/ScrollToTextFragment


On Fri, Jun 21, 2019 at 10:33 AM Adam Eisenreich  wrote:

> If you want to have native scrolling experience for `` you need to
> either implement your own scrolling behaviour, or you will create
> `` of size much bigger than screen, that way it overflows screen
> and shows scollbars, but then you must only render on part of canvas as
> most is hidden.
>
> I would like an API I would ask:
> If this element **would be scrollable**, when scrolling would actually
> occur? How long would the animation take on this platform? Where the end
> offset would be?
> Scrolling isn't same for each platform ex.: PC, Mac, iOS, Android.
>
> There is video about proxx, it mentions other problems too, but they
> explain there how they did implement natural scrolling for ``:
> https://youtu.be/ViyTYEv9dM8?t=1005
> ___
> 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: rest operator in middle of array

[kai zhu]

it matters when you have to debug/inherit *other* people's code (and clean
up their mess).  i wouldn't enjoy debugging unfamiliar-code that used this
feature (admittedly, its my subjective opinion).

the maintainability argument stands -- its counter-intuitive in javascript
that appending extra args to a function re-arranges arg-positioning and
invalidates existing calls.

debuggability is subjective i agree.

p.s. - in general, i don't see what *real* painpoint rest-operator actually
address, that couldn't be solved with `arguments`.  variable-arg-length
functions are not javascripty -- they frequently require extra ux-workflow
transformations like Function.p.apply or Array.p.flatmap to the arguments
being passed.


On Fri, Jun 7, 2019 at 10:07 AM Isiah Meadows 
wrote:

> For your maintainability argument: adding extra arguments to those
> functions is something I almost never do. And you'd have the same
> exact issue with final rest parameters, just in a different position
> (in the middle as opposed to in the end).
>
> For debuggability, I don't see how it'd be a major issue unless you
> already have an excessive number of *positional* parameters. In my
> experience, the debuggability issues arise approximately when there's
> just too many positional parameters, and factoring out the rest
> parameter to an array doesn't really help this situation much. (That's
> when object destructuring comes in handy.)
>
> So not convinced either is any different than what it's like today.
>
> Also, you aren't obligated to use a feature just because it exists - I
> hardly ever use proxies, for instance, and I rarely need maps beyond
> what objects give me, so I don't normally use them unless I need to
> have reference types or mixed types as keys.
>
> -
>
> Isiah Meadows
> cont...@isiahmeadows.com
> www.isiahmeadows.com
>
> On Thu, Jun 6, 2019 at 2:22 PM kai zhu  wrote:
> >
> > -1 for maintainability and debuggability
> >
> > 1. maintainability
> > if you want to extend the function with additional args,
> > then you'll have to retroactively modify all existing calls to avoid
> off-by-one argcount:
> >
> > ```js
> > // if extending function with additional args
> > function pad(targetLength, ...opts, data) ->
> > function pad(targetLength, ...opts, data, meta)
> >
> > // then must retroactively append null/undefined to all existing calls
> > pad(1, opt1, opt2, "data") ->
> > pad(1, opt1, opt2, "data", null)
> > ```
> >
> >
> >
> > 2. debuggability
> > when debugging, it takes longer for human to figure out which arg is
> what:
> >
> > ```js
> > // function pad(targetLength, ...opts, data)
> > pad(aa, bb, cc, dd);
> > pad(aa, bb, cc, dd, ee);
> >
> > // vs
> >
> > // function pad(targetLength, opts, data)
> > pad(aa, [bb, cc], dd);
> > pad(aa, [bb, cc, dd], ee);
> > ```
> >
> >
> >
> > On Thu, Jun 6, 2019 at 11:54 AM Ethan Resnick 
> wrote:
> >>
> >> Long-time mostly-lurker on here. I deeply appreciate all the hard work
> that folks here put into JS.
> >>
> >> I've run into a couple cases now where it'd be convenient to use a rest
> operator at the beginning or middle of an array destructuring, as in:
> >>
> >> ```
> >> const [...xs, y] = someArray;
> >> ```
> >>
> >> Or, similarly, in function signatures:
> >>
> >> ```
> >> function(...xs, y) { }
> >> ```
> >>
> >> The semantics would be simple: exhaust the iterable to create the array
> of `xs`, like a standard rest operator would do, but then slice off the
> last item and put it in `y`.
> >>
> >> For example, I was working with some variable argument functions that,
> in FP style, always take their data last. So I had a function like this:
> >>
> >> ```
> >> function match(...matchersAndData) {
> >>   const matchers = matchersAndData.slice(0, -1);
> >>   const data = matchersAndData[matchersAndData.length - 1];
> >>   // do matching against data
> >> }
> >> ```
> >>
> >> Under this proposal, the above could be rewritten:
> >>
> >> ```
> >> function reduce(...matchers, data) { /* ... */ }
> >> ```
> >>
> >> Another example: a function `pad`, which takes a target length and a
> string to pad, with an optional padding character argument in between:
> >>
> >> ```
> >> function pad(targetLength, ...paddingCharAndOrData) {
> >>   const [paddingChar = " "] = paddingCharA

Re: Proposal: rest operator in middle of array

[kai zhu]

-1 for maintainability and debuggability

1. maintainability
if you want to extend the function with additional args,
then you'll have to retroactively modify all existing calls to avoid
off-by-one argcount:

```js
// if extending function with additional args
function pad(targetLength, ...opts, data) ->
function pad(targetLength, ...opts, data, meta)

// then must retroactively append null/undefined to all existing calls
pad(1, opt1, opt2, "data") ->
pad(1, opt1, opt2, "data", null)
```



2. debuggability
when debugging, it takes longer for human to figure out which arg is what:

```js
// function pad(targetLength, ...opts, data)
pad(aa, bb, cc, dd);
pad(aa, bb, cc, dd, ee);

// vs

// function pad(targetLength, opts, data)
pad(aa, [bb, cc], dd);
pad(aa, [bb, cc, dd], ee);
```



On Thu, Jun 6, 2019 at 11:54 AM Ethan Resnick 
wrote:

> Long-time mostly-lurker on here. I deeply appreciate all the hard work
> that folks here put into JS.
>
> I've run into a couple cases now where it'd be convenient to use a rest
> operator at the beginning or middle of an array destructuring, as in:
>
> ```
> const [...xs, y] = someArray;
> ```
>
> Or, similarly, in function signatures:
>
> ```
> function(...xs, y) { }
> ```
>
> The semantics would be simple: exhaust the iterable to create the array of
> `xs`, like a standard rest operator would do, but then slice off the last
> item and put it in `y`.
>
> For example, I was working with some variable argument functions that, in
> FP style, always take their data last. So I had a function like this:
>
> ```
> function match(...matchersAndData) {
>   const matchers = matchersAndData.slice(0, -1);
>   const data = matchersAndData[matchersAndData.length - 1];
>   // do matching against data
> }
> ```
>
> Under this proposal, the above could be rewritten:
>
> ```
> function reduce(...matchers, data) { /* ... */ }
> ```
>
> Another example: a function `pad`, which takes a target length and a
> string to pad, with an optional padding character argument in between:
>
> ```
> function pad(targetLength, ...paddingCharAndOrData) {
>   const [paddingChar = " "] = paddingCharAndOrData.slice(0, -1);
>   const data = paddingCharAndOrData[paddingCharAndOrData.length - 1];
>
>   // pad data with paddingChar to targetLength;
> }
> ```
>
> With this proposal, that could be rewritten:
>
> ```
> function pad(targetLength, ...opts, data) {
>   const [paddingChar = " "] = opts;
>   // pad data with paddingChar to targetLength;
> }
> ```
>
> I'm curious if this has been considered before, and what people think of
> the idea.
>
> Obviously, if `...a` appeared at the beginning or middle of a list, there
> would have to be a fixed number of items following it, so a subsequent rest
> operator in the same list would not be allowed.
>
> Thanks
>
> ___
> 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: RegExp `x` flag

[kai zhu]

1. is this minifier-friendly?
2. is parsing-impact minimal enough to not affect load-times?
regexp-detection/bounding is among the most expensive/complex part of
javascript-parsing.

those 2 nits aside, i'm on the fence.  regexp-spaghetti is a valid
painpoint, and jslint's author has expressed desire for multiline regexp
[1].  otoh, there is a good-enough solution by falling-back to
constructor-form to improve readability:

```js
// real-world spaghetti-regexp code in jslint.js
const rx_token =
/^((\s+)|([a-zA-Z_$][a-zA-Z0-9_$]*)|[(){}\[\],:;'"~`]|\?\.?|=(?:==?|>)?|\.+|[*\/][*\/=]?|\+[=+]?|-[=\-]?|[\^%]=?|&[&=]?|\|[|=]?|>{1,3}=?|<)?"
+ "|\\.+"
+ "|[*\\/][*\\/=]?"
+ "|\\+[=+]?"
+ "|-[=\\-]?"
+ "|[\\^%]=?"
+ "|&[&=]?"
+ "|\\|[|=]?"
+ "|>{1,3}=?"
+ "| Even if this flag were restricted to constructors instead of both
> constructors and literals, it could be worthwhile.
>
> On Mon, Jun 3, 2019, 23:19 Isiah Meadows  wrote:
>
>> Let me clarify that previous message: I mean "newline restriction" in
>> the sense that newlines are not permitted in regexp literals. A `/x`
>> flag would make removing it practically required for it to have any
>> utility.
>>
>> -
>>
>> Isiah Meadows
>> cont...@isiahmeadows.com
>> www.isiahmeadows.com
>>
>> On Mon, Jun 3, 2019 at 11:14 PM Isiah Meadows 
>> wrote:
>> >
>> > I would personally love this (as well as interpolations in regexp
>> > literals). I do have a concern about whether removing the newline
>> > restriction creates ambiguities with division, but I suspect this is
>> > *not* the case.
>> >
>> > -
>> >
>> > Isiah Meadows
>> > cont...@isiahmeadows.com
>> > www.isiahmeadows.com
>> >
>> > On Mon, Jun 3, 2019 at 10:03 PM Jacob Pratt 
>> wrote:
>> > >
>> > > Has there been any previous discussion of adding the `x` flag to JS?
>> It exists in other languages, and can make relatively complicated regex
>> _much_ easier to read. It also allows for comments, which are incredibly
>> helpful when trying to understand some regexes.
>> > >
>> > > For prior art, XRegExp has this flag (though I've no idea to figure
>> out how frequently it's used), as do a few other languages.
>> > >
>> > > Quick overview: https://www.regular-expressions.info/freespacing.html
>> > >
>> > > Language references:
>> > > Python: https://docs.python.org/3/library/re.html#re.X
>> > > Rust: https://docs.rs/regex/1.1.6/regex/
>> > > XRegExp: http://xregexp.com/xregexp/flags/#extended
>> > > .NET:
>> https://docs.microsoft.com/en-us/dotnet/standard/base-types/regular-expression-language-quick-reference#regular-expression-options
>> > >
>> > > Jacob Pratt
>> > > ___
>> > > 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: how many async-modules can js-app practically load?

[kai zhu]

you would need to introduce a new language-syntax that hints delimited
module-scope, e.g.

```js
/*
 * es-module.rollup.js
 *
 * example rolling-up es-modules with [hypothetical] pragma
 * "use module_scope xxx";
 * which would be web-compat and minifier-friendly
 */

"use module_scope ./aa.js";
// foo is scoped inside module_scope ./aa.js
var foo = ...
...

"use module_scope ./bb.js";
// foo is scoped inside module_scope ./bb.js
var foo = ...
...
```

i'll be honest.  i'm not really proposing this language-syntax in
good-faith, as javascript is already chock-full of confusing-features that
are distracting/harmful to UX-workflow programming.

i'm mainly criticizing tc39 for their design-decision pushing through
es-modules, and how disruptive it is to operationalize (natively, w/o
transpiling) in production-systems.  web-development could've stayed
simpler if the committee had done absolutely nothing.  people would've
continued using es5-style rollups (w/ yui/amdjs-like module-loaders), and
devop-folks wouldn't be forced to deal with import-maps and http2-push to
solve a problem that shouldn't have existed.



On Sun, Jun 2, 2019 at 9:25 PM guest271314  wrote:

> > but that requires coordination among modules, which is not always
> possible.  the idea is to inline/rollup es-modules that may not have come
> from same developers (and whom are unaware their es-modules collide w/
> others when rolled-up).
>
> How do you intend to know the names of the identifiers to import without
> "coordination" and check for duplicate identifier names and duplicate
> exports?
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: how many async-modules can js-app practically load?

[kai zhu]

but that requires coordination among modules, which is not always
possible.  the idea is to inline/rollup es-modules that may not have come
from same developers (and whom are unaware their es-modules collide w/
others when rolled-up).

you should be able to natively transition from development-env (individual
es-modules) -> production-env (rolled-up es-modules), w/o down-transpiling
to es5-amdjs.



On Sun, Jun 2, 2019 at 8:29 PM guest271314  wrote:

> One option is to utilize ```shortName```
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#Import_an_export_with_a_more_convenient_alias
>
> ```
> import {foo as foo1} from "./aa.js";
> let bar1 = { baz: foo1 };
> export { bar1 };
>
> import {foo as foo2} from "./bb.js";
> const bar2 = { baz: foo2 };
> export { bar2 };
> ```
>
> On Sun, Jun 2, 2019 at 11:05 PM kai zhu  wrote:
>
>> not inline multiple ```export```'s, but inline multiple module-scopes.
>>
>> ```js
>> /*
>>  * how do you inline the two es-modules below
>>  * with colliding `foo` and `bar` variables?
>>  *
>>  * you can't unless you introduce new language-syntax
>>  * to somehow delimit their scopes
>>  */
>>
>> // [hypothethical] es-module-scope delimiter
>> # es-module-scope "./inline.js"
>>
>> // module ./inline.js
>> import { foo } from "./aa.js"
>> const bar = { baz: foo };
>> export { bar };
>>
>>
>>
>> // [hypothethical] es-module-scope delimiter
>> # es-module-scope ./nextinline.js
>>
>> // module ./nextinline.js
>> import { foo } from "./bb.js"
>> const bar = { baz: foo };
>> export { bar };
>> ```
>>
>> On Sun, Jun 2, 2019 at 2:54 PM guest271314  wrote:
>>
>>> Multiple imports are already possible
>>>
>>> ```
>>> import {inline} from "./inline.js";
>>> import {nextInline} from "./nextInline.js";
>>>
>>> const o = {
>>>   a:1, b:2, c:3
>>> };
>>>
>>> // ...
>>>
>>> export {o, cities, video, inline, nextInline};
>>> ```
>>>
>>> Are you proposing multiple ```export```s?
>>>
>>> ```
>>> export {o, cities, video, inline, nextInline};
>>> o.c = 7;
>>> export {o};
>>> ```
>>>
>>>
>>>
>>> On Sun, Jun 2, 2019 at 6:19 PM kai zhu  wrote:
>>>
>>>> @guest271314 , your example again is not a
>>>> [native] bundle of two or more inlined es-modules.  its just a single
>>>> es-module that that fetches json data.
>>>>
>>>> i'm asking if its desirable to inline multiple es-modules into a single
>>>> file natively, e.g.:
>>>>
>>>> ```
>>>> /*
>>>>  * es-module.rollup.js
>>>>  * this [hypothetical] rollup-file contains multiple inlined es-modules
>>>>  * to improve load-performance in production-deployment.
>>>>  */
>>>>
>>>> // 1. inlined es-module ./main.js
>>>> import { foo } from "./counter.js"
>>>> import { bar } from "./display.js"
>>>> foo(bar);
>>>>
>>>> // 2. inlined es-module ./counter.js
>>>> var foo;
>>>> foo = function (bar) {
>>>> bar();
>>>> };
>>>> export { foo }
>>>>
>>>> // 3. inlined es-module ./display.js
>>>> var bar;
>>>> bar = function () {
>>>> console.log("hello world");
>>>> };
>>>> export { bar }
>>>> ```
>>>>
>>>> this native es-module inline-capability may not be desirable to you,
>>>> which is fine.  it would be a datapoint against this feature (and rely
>>>> instead on pre-emptive import-maps and http2-push, as explained by
>>>> @frederick and @isiah).
>>>>
>>>>
>>>> On Sun, Jun 2, 2019 at 11:22 AM guest271314 
>>>> wrote:
>>>>
>>>>> 1) original-question - is native es-module's async-behavior
>>>>>> desirable?  async side-effects are difficult to manage -- i conjecture 
>>>>>> that
>>>>>> async-loading 20 es-modules (with dependent side-effects) is not 
>>>>>> practical
>>>>>> for most mortals to handle.
>>>>>
>>>>>
>>>>> It depends on what *you *mean by "desirable" in a given context.
>>&g

Re: how many async-modules can js-app practically load?

[kai zhu]

not inline multiple ```export```'s, but inline multiple module-scopes.

```js
/*
 * how do you inline the two es-modules below
 * with colliding `foo` and `bar` variables?
 *
 * you can't unless you introduce new language-syntax
 * to somehow delimit their scopes
 */

// [hypothethical] es-module-scope delimiter
# es-module-scope "./inline.js"

// module ./inline.js
import { foo } from "./aa.js"
const bar = { baz: foo };
export { bar };



// [hypothethical] es-module-scope delimiter
# es-module-scope ./nextinline.js

// module ./nextinline.js
import { foo } from "./bb.js"
const bar = { baz: foo };
export { bar };
```

On Sun, Jun 2, 2019 at 2:54 PM guest271314  wrote:

> Multiple imports are already possible
>
> ```
> import {inline} from "./inline.js";
> import {nextInline} from "./nextInline.js";
>
> const o = {
>   a:1, b:2, c:3
> };
>
> // ...
>
> export {o, cities, video, inline, nextInline};
> ```
>
> Are you proposing multiple ```export```s?
>
> ```
> export {o, cities, video, inline, nextInline};
> o.c = 7;
> export {o};
> ```
>
>
>
> On Sun, Jun 2, 2019 at 6:19 PM kai zhu  wrote:
>
>> @guest271314 , your example again is not a
>> [native] bundle of two or more inlined es-modules.  its just a single
>> es-module that that fetches json data.
>>
>> i'm asking if its desirable to inline multiple es-modules into a single
>> file natively, e.g.:
>>
>> ```
>> /*
>>  * es-module.rollup.js
>>  * this [hypothetical] rollup-file contains multiple inlined es-modules
>>  * to improve load-performance in production-deployment.
>>  */
>>
>> // 1. inlined es-module ./main.js
>> import { foo } from "./counter.js"
>> import { bar } from "./display.js"
>> foo(bar);
>>
>> // 2. inlined es-module ./counter.js
>> var foo;
>> foo = function (bar) {
>> bar();
>> };
>> export { foo }
>>
>> // 3. inlined es-module ./display.js
>> var bar;
>> bar = function () {
>> console.log("hello world");
>> };
>> export { bar }
>> ```
>>
>> this native es-module inline-capability may not be desirable to you,
>> which is fine.  it would be a datapoint against this feature (and rely
>> instead on pre-emptive import-maps and http2-push, as explained by
>> @frederick and @isiah).
>>
>>
>> On Sun, Jun 2, 2019 at 11:22 AM guest271314 
>> wrote:
>>
>>> 1) original-question - is native es-module's async-behavior desirable?
>>>> async side-effects are difficult to manage -- i conjecture that
>>>> async-loading 20 es-modules (with dependent side-effects) is not practical
>>>> for most mortals to handle.
>>>
>>>
>>> It depends on what *you *mean by "desirable" in a given context.
>>>
>>> There is no difference from loading 1 module and loading 1000 modules
>>> except for network cost, memory and disk space usage.
>>>
>>> Mortals can handle far more than loading 20 es-modules.
>>>
>>> What are the specific  "side-effects" that you are referring to?
>>>
>>> describes the mechanism for how to hint the brower to pre-fetch 20
>>>> es-modules. but if you pre-fetch, then is loading-behavior effectively
>>>> synchronous?
>>>
>>>
>>> Resources can be "pre-fetched" using various means. From caching the
>>> first request and using the cached data instead of making future requests
>>> for the same resources to storing one or more entire directories in the
>>> browser configuration folder using `requestFileSystem` (Chromiom/Chrome).
>>>
>>> but was unclear whether they were individual [async] ```>>> type="module">``` tags, or some es5-transpiled rollup
>>>
>>>
>>> There should not be any difference between the two approaches. If there
>>> is a difference then you should be able to clearly state what the
>>> difference is, and demonstrate the difference by reproduction, without
>>> speculating and not demonstrating a difference by means of reproduction.
>>>
>>> 2) the second-question about es-module rollups (which you and i are
>>>> debating) stemmed from @isiah's response -- if he and everyone-else use
>>>> es5-transpiled rollups (which i suspect),
>>>
>>>
>>> Do not care what "everyone-else" is supposedly doing. How can you
>>> possibly know what everyone-else is doing and even if you did know what

Re: how many async-modules can js-app practically load?

[kai zhu]

@guest271314 , your example again is not a [native]
bundle of two or more inlined es-modules.  its just a single es-module that
that fetches json data.

i'm asking if its desirable to inline multiple es-modules into a single
file natively, e.g.:

```
/*
 * es-module.rollup.js
 * this [hypothetical] rollup-file contains multiple inlined es-modules
 * to improve load-performance in production-deployment.
 */

// 1. inlined es-module ./main.js
import { foo } from "./counter.js"
import { bar } from "./display.js"
foo(bar);

// 2. inlined es-module ./counter.js
var foo;
foo = function (bar) {
bar();
};
export { foo }

// 3. inlined es-module ./display.js
var bar;
bar = function () {
console.log("hello world");
};
export { bar }
```

this native es-module inline-capability may not be desirable to you, which
is fine.  it would be a datapoint against this feature (and rely instead on
pre-emptive import-maps and http2-push, as explained by @frederick and
@isiah).


On Sun, Jun 2, 2019 at 11:22 AM guest271314  wrote:

> 1) original-question - is native es-module's async-behavior desirable?
>> async side-effects are difficult to manage -- i conjecture that
>> async-loading 20 es-modules (with dependent side-effects) is not practical
>> for most mortals to handle.
>
>
> It depends on what *you *mean by "desirable" in a given context.
>
> There is no difference from loading 1 module and loading 1000 modules
> except for network cost, memory and disk space usage.
>
> Mortals can handle far more than loading 20 es-modules.
>
> What are the specific  "side-effects" that you are referring to?
>
> describes the mechanism for how to hint the brower to pre-fetch 20
>> es-modules. but if you pre-fetch, then is loading-behavior effectively
>> synchronous?
>
>
> Resources can be "pre-fetched" using various means. From caching the first
> request and using the cached data instead of making future requests for the
> same resources to storing one or more entire directories in the browser
> configuration folder using `requestFileSystem` (Chromiom/Chrome).
>
> but was unclear whether they were individual [async] ```> type="module">``` tags, or some es5-transpiled rollup
>
>
> There should not be any difference between the two approaches. If there is
> a difference then you should be able to clearly state what the difference
> is, and demonstrate the difference by reproduction, without speculating and
> not demonstrating a difference by means of reproduction.
>
> 2) the second-question about es-module rollups (which you and i are
>> debating) stemmed from @isiah's response -- if he and everyone-else use
>> es5-transpiled rollups (which i suspect),
>
>
> Do not care what "everyone-else" is supposedly doing. How can you possibly
> know what everyone-else is doing and even if you did know what
> third-parties are doing how does that affect what you are doing?
>
> then shouldn't it be desirable for es-modules to natively support rollups
>> as well?  currently, there's no way to natively rollup multiple es-modules
>> into a single bundle.
>
>
> There are ways to "bundle" multiple modules into a single export
> "natively", as demonstrated at the previously posted code.
>
> Another example approach
>
> ```
> // sync
> const o = {
>   a:1, b:2, c:3
> };
> // async
> const cities = fetch("
> <a  rel="nofollow" href="https://gist.githubusercontent.com/guest271314/ffac94353ab16f42160e/raw/aaee70a3e351f6c7bc00178eabb5970a02df87e9/states.json">https://gist.githubusercontent.com/guest271314/ffac94353ab16f42160e/raw/aaee70a3e351f6c7bc00178eabb5970a02df87e9/states.json</a>
> ")
>.then(response => response.json())
>.catch(e => {console.error(e); return "error fetching
> cities module"});
> // async
> const video = fetch("
> <a  rel="nofollow" href="https://upload.wikimedia.org/wikipedia/commons/d/d9/120-cell.ogv&quot">https://upload.wikimedia.org/wikipedia/commons/d/d9/120-cell.ogv&quot</a>;)
>.then(response => response.blob())
>   .catch(e => {console.error(e); return "error fetching video
> module"});
> // multiple "modules" exported
> export {o, cities, video};
> ```
>
> at single ```<script type="module">```
>
> ```
> <script type="module">
>   import * as o from "./script.js";
>   (async(mods) => {
> for (const [key, value] of mods) {
>   if (value instanceof Promise) {
> console.log("asy

Re: how many async-modules can js-app practically load?

[kai zhu]

i apologize for poor framing of my questions.  they are still formative,
but i can clarify abit as follows:

1) original-question - is native es-module's async-behavior desirable?
async side-effects are difficult to manage -- i conjecture that
async-loading 20 es-modules (with dependent side-effects) is not practical
for most mortals to handle.
@frederick describes the mechanism for how to hint the brower to pre-fetch
20 es-modules. but if you pre-fetch, then is loading-behavior effectively
synchronous?
@isiah says he has experience loading 50-100 modules, but was unclear
whether they were individual [async] 

Re: how many async-modules can js-app practically load?

[kai zhu]

i played around with your code in jsfiddle [1], and understand it a little
more.
it doesn't actually ```import``` 1000+ es-modules inside the rollup-file.
it just creates one es-module that exports a dictionary
 -- and assigns the dictionary 1000+ vanilla json-objects and functions.

```js
// the "rollup-file" is a single es-module
// that exports 1000+ vanilla dictionary-entries
const modules = {};

// this is not a es-module, nor is it rolled-up (external fetch)
modules.image = 

// this is not a [rolled-up] es-module
modules.fn = function () {...}

// these are not [rolled-up] es-modules
Object.assign(modules, <1000 json-entries>)

export {modules}
```

currently, as i'm aware, nobody uses native es-modules in production,
because it cannot be rolled-up.
in practice es-modules are [babel] transpiled down to es5-amd (or similar)
for rollup-purposes.

if we're actually committed to native es-modules, then we either
1) need to depend on embedders like loading-...@chromium.org to create
sophisticated cache-systems, or
2) introduce new language-syntax to delimit es-modules for rollup-purposes,
e.g.

```js
// rollup.js with [hypothetical] # delimited es-modules
# module aa
import {bb} as bb;
export ...;

# module bb
export ...;
```

i'm generally skeptical of option 1, given how poorly npmjs.com has handled
similar problems deduplicating children in node_modules/ directory.

[1] jsfiddle pseudo-module rollup
https://jsfiddle.net/06twrLfd/

On Sat, Jun 1, 2019 at 5:30 PM guest271314  wrote:

> > your rollup solution is interesting,
>
> What  is "rollup" referring to?
>
> > but i get an error when run in chrome (i changed to n=20 to prevent
> name-collision, but it still happens).
>
> The duplicate ("collision") entry an ```try..catch``` block is included in
> the code to demonstrate given an array of module names to be exported and
> imported as identifiers 1) duplicate entries can be filtered; 2) if a plain
> object is exported duplicate identifiers ("collision") is not possible as a
> JavaScript plain object does not have duplicate property names
> ("collision"); if there is an issue with identifiers in a module the cause
> would not be the number of async-modules loaded ("how many"), but the
> naming of the identifiers within the code, using or not using ```const```
> or ```let```. Still not sure what the actual issue is?
>
> > don't completely understand how it works,
>
> Use an ```async``` function to fetch data, check for the described
> "collision" , create a ```data URI``` to be imported, optionally, append
> addition code to be executed within the 

Re: how many async-modules can js-app practically load?

[kai zhu]

your rollup solution is interesting, but i get an error when run in chrome
(i changed to n=20 to prevent name-collision, but it still happens).  don't
completely understand how it works, but not sure of suitability for
production-use, because of its dynamic 

Re: how many async-modules can js-app practically load?

[kai zhu]

> Place all of the code to be exported in 1 file?

that obviously will not work, because of module-scope collision.  can
anyone share their experience on deploying a [babel-free] pure-es6
application with 20 es-modules rolled-up into one [production] bundle?  is
it even possible?


On Fri, May 31, 2019 at 7:55 PM guest271314  wrote:

> > how would i transition from development-mode (20 es-module files) ->
> production-mode (1 rollup file)?
>
> Place all of the code to be exported in 1 file?
>
> > with some of them having circular-references
>
> Not certain how that is possible when using ```import``` within 

Re: how many async-modules can js-app practically load?

[kai zhu]

> Oh, and yes, I've loaded upwards of 50-100 modules in development. 20
modules is *easy* to achieve in single-page apps.

was that with some combination of babel/rollup/webpack or pure-es6?
if i want to develop a pure-es6 webapp (no babel), how would i transition
from development-mode (20 es-module files) -> production-mode (1 rollup
file)?


On Fri, May 31, 2019 at 10:47 AM Isiah Meadows 
wrote:

> If it's bundled by Rollup or Webpack into a single bundle, it's
> equivalent to a single 

Re: how many async-modules can js-app practically load?

[kai zhu]

> Why would 50 separate 

Re: how many async-modules can js-app practically load?

[kai zhu]

> Asynchronous loading differs only in
> that it takes more code to express the same logic and you have to take
> into account concurrent requests (and you need to cache the request,
> not the result), but it's otherwise the same from 1km away.

so async-loading 50 

Re: how many async-modules can js-app practically load?

[kai zhu]

actually, i admit i don't know what i'm talking about.  just generally
confused (through ignorance) on how large-scale es-module dependencies
resolve when loaded/imported asynchronously.

On Wed, May 22, 2019 at 10:42 PM Logan Smyth  wrote:

> Can you elaborate on what loading state you need to keep track of? What is
> the bottleneck that you run into? Also to be sure, when you say async-load,
> do you mean `import()`?
>
> On Wed, May 22, 2019, 20:17 kai zhu  wrote:
>
>> i don't use es-modules.
>> but with amd/requirejs, I start having trouble with
>> module-initializations in nodejs/browser at ~5 async modules (that may or
>> may not have circular-references).  10 would be hard, and 20 would be near
>> inhuman for me.
>>
>> can we say its somewhat impractical for most applications to load more
>> than 50 async modules (with some of them having circular-references)?  and
>> perhaps better design/spec module-loading mechanisms with this usability
>> concern in mind?
>>
>> p.s. its also impractical for me to async-load 5 or more modules without
>> using globalThis to keep track of each module's loading-state.
>> ___
>> 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

how many async-modules can js-app practically load?

[kai zhu]

i don't use es-modules.
but with amd/requirejs, I start having trouble with module-initializations
in nodejs/browser at ~5 async modules (that may or may not have
circular-references).  10 would be hard, and 20 would be near inhuman for
me.

can we say its somewhat impractical for most applications to load more than
50 async modules (with some of them having circular-references)?  and
perhaps better design/spec module-loading mechanisms with this usability
concern in mind?

p.s. its also impractical for me to async-load 5 or more modules without
using globalThis to keep track of each module's loading-state.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal: native XML object support.

[kai zhu]

jsx is not terribly javascripty ... vs direct manipulation of the dom
(using static-functions/handlers).

it requires two extra ux-workflow transformations -- 1) transpilation and
2) virtual-dom manipulation, for the sake of oft-quoted faster
dom-performance, which some like me are skeptical is true in modern
browsers.

-kai


On Tue, May 21, 2019, 16:35 Andrea Giammarchi 
wrote:

> People use JSX, which is basically E4X, so I'd argue the word useless is
> not really appropriate. You can use E4X to produce HTML, the fact we're
> talking XML is merely about the E4X background, but as you could produce
> strings out of E4X you could do the same and have better templating out of
> the box.
>
> But like I've said, I already use template literal tags, but those strings
> don't get hints or highlights as if these were E4X, XML, or plain HTML,
> which is the only cool thing I'd personally find useful.
>
> Maybe it's just a tooling issue though.
>
> On Mon, May 20, 2019 at 3:06 PM ViliusCreator 
> wrote:
>
>> > the client, it could still somehow shine in NodeJS though.
>>
>>
>>
>> The only way it can shine is only passing HTML objects as arg to website.
>> That’s it. And still, you can use string to do that for you. People already
>> use JSON and I don’t think they would use XML in Node js. There are already
>> tons of libs for XML stuff, yet they don’t have a lot of downloads, as far
>> as I remember.
>>
>>
>>
>> So basically, Node js doesn’t need XML. That would be useless.
>> ___
>> 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: native XML object support.

[kai zhu]

fyi, a notable xml-based web-api holdout is wechat-pay, with a billion
active users [1],[2]. arch-rival alipay otoh uses json.

-kai

[1] official wechat-pay documentation
https://pay.weixin.qq.com/wiki/doc/api/download/wxpay_document.zip

[2] swagger documentation for wechat-pay
https://kaizhu256.github.io/node-swgg-wechat-pay/build..beta..travis-ci.org/app/



On Tue, May 21, 2019, 05:08 Michał Wadas  wrote:

> I'm not sure why is that discussed. XML is natively supported in browsers
> and there are npm packages to bring exactly the same interface to Node.js
> and other server envs.
>
> If you want Node.js to include some kind of XML parser in its core
> library, I suggest using their bug tracker (but it was rejected 4 years ago
> - https://github.com/nodejs/node/issues/2709 ).
>
> On Mon, May 20, 2019 at 9:35 PM Isiah Meadows 
> wrote:
>
>> My bad. I should've known that. :-)
>>
>> (I've looked *way* too deeply into the React/Redux ecosystem to have
>> any sort of excuse on this one.)
>>
>> -
>>
>> Isiah Meadows
>> cont...@isiahmeadows.com
>> www.isiahmeadows.com
>>
>> On Wed, May 15, 2019 at 11:39 PM Jordan Harband  wrote:
>> >
>> > (that's not react's creator; that's redux's creator, who is now a
>> member of the react core team)
>> >
>> > On Wed, May 15, 2019 at 8:17 PM Isiah Meadows 
>> wrote:
>> >>
>> >> Fun fact: React elements are plain JS objects that are nearly
>> JSON-compatible. The only reason why they aren't is because of the presence
>> of a `$$typeof: Symbol.for("react.element")` property on React elements, to
>> prevent people from using non-array object results of
>> `JSON.parse(jsonString)` directly as a child. The rationale for this is
>> explained in this blog post by React's creator:
>> >> https://overreacted.io/why-do-react-elements-have-typeof-property/
>> >>
>> >> I would say that we live in a JSON-centric world for APIs,
>> SGML/XML-centric for UIs. (I wish XHTML efforts actually stuck, to be
>> honest. `` is one reason XML would've been better than
>> SGML IMHO.)
>> >>
>> >> On Tue, May 14, 2019 at 01:47 Ed Saleh  wrote:
>> >>>
>> >>> Thanks for reply. Didn't know that it existed before!
>> >>> I don't think we can say that we live in a JSON centric world when
>> things like React show up and revolutionize web development. I think JSON
>> has its uses and XML has its uses. UI shouldn't been ever seperated from
>> controller since one can't exist without the other.
>> >>> 
>> >>> From: es-discuss  on behalf of
>> Sanford Whiteman 
>> >>> Sent: Tuesday, May 14, 2019 1:37:46 AM
>> >>> To: es-discuss@mozilla.org
>> >>> Subject: Re: Proposal: native XML object support.
>> >>>
>> >>> > let foo = 
>> >>>
>> >>> This is a retread of E4X (
>> https://en.wikipedia.org/wiki/ECMAScript_for_XML)
>> >>> so I can't imagine it would be resuscitated in a (for better or
>> worse) JSON-centric
>> >>> world.
>> >>>
>> >>> —— Sandy
>> >>>
>> >>> ___
>> >>> 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
>> >>
>> >> --
>> >> -
>> >>
>> >> Isiah Meadows
>> >> cont...@isiahmeadows.com
>> >> www.isiahmeadows.com
>> >> ___
>> >> 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

javascripty-ness or python-like idioms for javascript

[kai zhu]

coming from a python background, it would be nice if javascript had some
core design-philosophy to guide its evolution rather than haphazardly
following fads and cues from other languages.  currently, my strawman idea
of what constitutes javascripty-ness is:

"achieving your ux-workflow objective, such that passing end-to-end data
between [client/server/storage] nodes and components requires the fewest
and least-complicated transformation-steps possible."

for example, i wouldn't consider the temporal-proposal very javascripty,
since it uses excessive [class] transformations to baton-pass datetime
between nodes, compared to say ... using static-functions that input/output
mostly canonical-isostrings.
___
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

[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

[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

[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

Re: Proposal: Static Typing

[kai zhu]

i share a similar concern that static-typing makes little sense in 
high-churn-rate UX-workflow-programming.

it encourage people to bikeshed for correctness, on low-level code that 
frequently gets rewritten every few weeks/months -- and with often demoralizing 
effects.

> On 24 Mar 2019, at 17:26, Bergi  wrote:
> 
> Hello,
> to play the devils advocate: why does JavaScript need static typing?
> 
> Your proposal doesn't really answer that. Sure, it mentions tooling and
> IDEs that can provide you with type hints and complain on mistakes, but
> things like Flow and Typescript do this today already.
> What's your goal, to have JS engines run Typescript(-like) code natively
> without transpiling? For backwards-compatibility you'd have to do that
> anyway, especially if new type system features are introduced incrementally.
> 
> What's the point of building this feature into engines? It just provides
> additional complexity. Not to mention the difficulty of finding a
> suitable type system that is both sophisticated enough to describe all
> useful code (not taking away too much flexibility) and simple enough to
> understand without a CS degree. And which interfaces well with un-typed
> completely dynamic code.
> 
> What does "static typing" even mean to you in a dynamic scripting
> language? JavaScript is not compiled by the developer, it is run by the
> user. Where (when) do you expect types to be checked? Should the engine
> throw early errors (during parsing)? During parsing of which parts of
> the code, even when "normal" (untyped) code is calling into typed code?
> Or do you expect dynamic runtime errors, like when assigning an invalid
> value to a "typed variable" or calling a "typed function" with wrong
> arguments? Are type definitions completely constant or could they be
> mutated/extended/etc dynamically (and what happens when you introduce
> new types with `eval` or by loading another script)?
> 
> A proposal would need to provide an objective that answers all these
> questions, before even considering any particular type system or syntax.
> 
> One way to go forward that I can see would be a proposal that reserves a
> relatively unrestricted syntax for type annotations (which are already
> considered during every grammar amendment anyway, for compatibility with
> Flow/Typescript), but not assign any semantics to them and require
> engines to simply ignore them. External tooling could then use these
> annotations according to its own rules.
> 
> 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: switch expressions

[kai zhu]

> This is unmaintainable -- 
> 
> const x = v === 'foo' ? 1 : v === 'bar' ? 3 : v === 'baz' ? 6 : 99;  
> 
i feel proposed switch-expressions are no more readable/maintainable than 
ternary-operators, if you follow jslint's style-guide.  i'll like to see more 
convincing evidence/use-case that they are better:

```javascript
/*jslint*/
"use strict";
const v = "foo";
const x = (
v === "foo"
? 1
: v === "bar"
? 3
: v === "baz"
? 6
: 99
);
```

here's another example from real-world production-code, where 
switch-expressions probably wouldn't help:

```javascript
$ node -e '
/*jslint devel*/
"use strict";
function renderRecent(date) {
/*
 * this function will render  to "xxx ago"
 */
date = Math.ceil((Date.now() - new Date(date).getTime()) * 0.0001) * 10;
return (
!Number.isFinite(date)
? ""
: date < 60
? date + " sec ago"
: date < 3600
? Math.round(date / 60) + " min ago"
: date < 86400
? Math.round(date / 3600) + " hr ago"
: date < 129600
? "1 day ago"
: Math.round(date / 86400) + " days ago"
);
}

console.log(renderRecent(new Date().toISOString())); // "0 sec ago"
console.log(renderRecent("2019-02-28T05:32:00Z")); // "10 sec ago"
console.log(renderRecent("2019-02-28T05:27:30Z")); // "5 min ago"
console.log(renderRecent("2019-02-28T05:14:00Z")); // "18 min ago"
console.log(renderRecent("2019-02-28T03:27:00Z")); // "2 hr ago"
console.log(renderRecent("2019-02-12T05:27:00Z")); // "16 days ago"
console.log(renderRecent("2018-02-28T05:27:00Z")); // "365 days ago"
'

0 sec ago
10 sec ago
5 min ago
18 min ago
2 hr ago
16 days ago
365 days ago

$
```

> On 27 Feb 2019, at 13:12, David Koblas  wrote:
> 
> Just for folks who might be interested, added a babel-plugin to see what was 
> involved in making this possible.
> 
> Pull request available here -- https://github.com/babel/babel/pull/9604
> 
> I'm sure I'm missing a bunch of details, but would be interested in some help 
> in making this a bit more real.
> 
> Thanks
> 
> On 2/26/19 2:40 PM, Isiah Meadows wrote:
>> You're not alone in wanting pattern matching to be expression-based:
>> 
>> https://github.com/tc39/proposal-pattern-matching/issues/116
>> 
>> -
>> 
>> Isiah Meadows
>> cont...@isiahmeadows.com
>> www.isiahmeadows.com
>> 
>> -
>> 
>> Isiah Meadows
>> cont...@isiahmeadows.com
>> www.isiahmeadows.com
>> 
>> 
>> On Tue, Feb 26, 2019 at 1:34 PM David Koblas  wrote:
>>> Jordan,
>>> 
>>> Thanks for taking time to read and provide thoughts.
>>> 
>>> I just back and re-read the pattern matching proposal and it still fails on 
>>> the basic requirement of being an Expression not a Statement.  The problem 
>>> that I see and want to address is the need to have something that removes 
>>> the need to chain trinary expressions together to have an Expression.
>>> 
>>> This is unmaintainable --
>>> 
>>> const x = v === 'foo' ? 1 : v === 'bar' ? 3 : v === 'baz' ? 6 : 99;
>>> 
>>> This is maintainable, but is less than ideal:
>>> 
>>>let x;
>>> 
>>>switch (v) {
>>>case "foo":
>>>  x = 1;
>>>  break;
>>>case "bar":
>>>  x = 3;
>>>  break;
>>>case "baz":
>>>  x = 6;
>>>  break;
>>>default:
>>>  x = 99;
>>>  break;
>>>}
>>> 
>>> Pattern matching does shorten the code, but you have a weird default case 
>>> and also still end up with a loose variable and since pattern matching is a 
>>> statement you still have a initially undefined variable.
>>> 
>>>let x;
>>> 
>>>case (v) {
>>>  when "foo" -> x = 1;
>>>  when "bar" -> x = 3;
>>>  when "baz" -> x = 6;
>>>  when v -> x = 99;
>>>}
>>> 
>>> Let's try do expressions, I'll leave people's thoughts to themselves.
>>> 
>>>const x = do {
>>>  if (v === "foo") { 1; }
>>>  else if (v === "bar") { 3; }
>>>  else if (v === "baz") { 6; }
>>>  else { 99; }
>>>}
>>> 
>>> Or as another do expression variant:
>>> 
>>>const x = do {
>>>  switch (v) {
>>>case "foo": 1; break;
>>>case "bar": 3; break;
>>>case "baz": 6; break;
>>>default: 99; break;
>>>  }
>>>}
>>> 
>>> And as I'm thinking about switch expressions:
>>> 
>>>const x = switch (v) {
>>>  case "foo" => 1;
>>>  case "bar" => 3;
>>>  case "baz" => 6;
>>>  default => 99;
>>>}
>>> 
>>> What I really like is that it preserves all of the normal JavaScript syntax 
>>> with the small change that a switch is allowed in an expression provided 
>>> that all of the cases evaluate to expressions hence the use of the '=>' as 
>>> an indicator.  Fundamentally this is a very basic concept where you have a 
>>> state machine and need it switch based on the current state and evaluate to 
>>> the new state.
>>> 
>>>const nextState = switch (currentState) {
>>>   case ... =>
>>>}
>>> 
>>> 
>>> 
>>> On 2/25/19 4:00 PM, Jordan Harband wrote:
>>> 
>>> Pattern 

Re: Function Overloading or Pattern Matching of functions in Ecma

[kai zhu]

gt; 
> ```js
> function sum_list(input, result = 0) case (input) {
> when [head, ...tail] -> {
> return sum_list(input, result + head);
> },
> when _ -> { return result; }
> }
> ```  
> 
> 
> - Matthew Robb
> 
> 
> On Mon, Oct 22, 2018 at 8:48 AM Isiah Meadows  <mailto:isiahmead...@gmail.com>> wrote:
> As mentioned previously, the pattern matching proposal does a lot to help 
> here:
> 
> ```js
> function sum_list(input, result = 0) {
> case (input) {
> when [head, ...tail] -> return sum_list(input, result + head),
> when _ -> return result,
> };
> }
> ```
> 
> -
> 
> Isiah Meadows
> cont...@isiahmeadows.com <mailto:cont...@isiahmeadows.com>
> www.isiahmeadows.com <http://www.isiahmeadows.com/>
> 
> On Mon, Oct 22, 2018 at 3:08 AM bishwendu kundu  <mailto:bishwenduk...@gmail.com>> wrote:
> >
> > Hi Kai Zhu,
> >
> > I agree with you the new proposition should be of value to a web developer 
> > in daily work. If we observe the pattern it more closely resembles a more 
> > declarative form of solution implementation which is easy to code and 
> > understand. For example lets consider below piece of code:
> > ```js
> > function sum_list(input, result){
> > if(!input.length)
> > return result;
> >     [head, ...input] = input;
> > return sum_list(input, result + head);
> > }
> > ```
> > Now the same code in the new proposal form
> >
> > ```js
> > function sum_list([head, ...tail], result){
> > result = result + head;
> > return sum_list(tail, result);
> > }
> >
> > function sum_list([], result){
> > return result;
> > }
> > ```
> >
> > This declarative model of coding also forces an immutable form of state 
> > management allowing for removing a family of bugs.
> >
> > Thanks & Regards,
> > Bishwendu.
> >
> > On Wed, Oct 17, 2018 at 12:57 PM kai zhu  > <mailto:kaizhu...@gmail.com>> wrote:
> >>
> >> hi Bishwendu, javascript is first-and-foremost a tool designed for 
> >> web-product-development, a growing field that has eclipsed low-level 
> >> general-purpose programming (where jobs are harder and harder to find) in 
> >> the IT industry.
> >>
> >> you need to give compelling reasons (for such significant language-change) 
> >> why i, a web-developer would benefit from from having overloaded-functions 
> >> in my (mostly expendable-code) web-projects, as opposed to creating 
> >> confusion and maintennance-headaches, when i typically have to rewrite 
> >> code multiple-times during the web-integration process.
> >>
> >> kai zhu
> >> kaizhu...@gmail.com <mailto:kaizhu...@gmail.com>
> >>
> >>
> >>
> >> On 17 Oct 2018, at 12:23 PM, bishwendu kundu  >> <mailto:bishwenduk...@gmail.com>> wrote:
> >>
> >> Hello All,
> >>
> >> I have been a great fan of the evolution of JavaScript in the recent past. 
> >> The language is steadily closing the gap to ideal functional paradigm. One 
> >> of the things that I have liked the most about languages like 
> >> Erlang/Elixir/Haskell is their ability to define functions with same name 
> >> and different airty. The decision of invoking the correct 
> >> function-argument pattern is dependent on the invocation of the function. 
> >> Implicit pattern matching in aforementioned languages helps avoid costly 
> >> cognitive loads introduced by explicit if/else based pattern of logic flow 
> >> branching.
> >>
> >> The greatest power of the pattern matching which amazed me was, dropping 
> >> the whole of looping construct, altogether. Elixir/Erlang have no LOOPS. 
> >> Stack based recursive calls combined with JavaScript's closures suddenly 
> >> strikes me as a very powerful programming model that not only increases 
> >> readability of code but also promotes immutability of the data structures 
> >> in use. The loops would continue to exist but more modern codes can be 
> >> written leveraging the recursive model of JavaScript.
> >>
> >> With de-structuring of arrays & objects already in place in JavaScript, 
> >> pattern-matching of functions can fit right in perfectly, thereby taking 
> >> JavaScript another step closer to ideal functional programming model.
> >>
> >> Looking forward to your response

Re: add stage4 constraint - ease-of-minification

[kai zhu]

> I just have a copy of  npm\node_modules\google-closure-compiler/compiler.jar


good to know.  also, the previous benchmark was misleading, because terser 
didn’t mangle by default [1]. with mangling, its performance is inline:

```shell

npm install google-closure-compiler terser uglifyjs-lite
curl -O https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.js 

npx google-closure-compiler jquery.js > jquery.min.google 
-closure-compiler.js 2>/dev/null
npx uglifyjs-lite jquery.js > jquery.min.uglifyjs-lite.js 2>/dev/null
npx terser jquery.js -m > jquery.min.terser-mangled.js
npx terser jquery.js -c -m > jquery.min.terser-compressed-mangled.js 2>/dev/null
npx terser jquery.js -c -m --mangle-props > 
jquery.min.terser-compressed-props-mangled.js 2>/dev/null
ls -lS jquery.*
  271751 Feb 14 13:12 jquery.js
   91350 Feb 14 13:24 jquery.min.terser-mangled.js
   89845 Feb 14 13:24 jquery.min.google 
-closure-compiler.js
   88681 Feb 14 13:24 jquery.min.uglifyjs-lite.js
   86478 Feb 14 13:24 jquery.min.terser-compressed-mangled.js
   79896 Feb 14 13:24 jquery.min.terser-compressed-props-mangled.js


```
[1] https://github.com/terser-js/terser/issues/266 
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: add stage4 constraint - ease-of-minification

[kai zhu]

fyi, i benchmarked minification-performance of google-closure-compiler and 
terser against a "classic" es5-compiler (uglifyjs-lite).  
google-closure-compiler is comparable to es5-compiler (but slow to compile), 
while terser is significantly worse:

minifiying jquery-v3.3.1.js
uminified: 271,751 bytes (100.0%)
terser (es6):  137,538 bytes ( 50.6%)
google-closure-compiler (es6):  89,845 bytes ( 33.1%)
uglifyjs-lite (es5):88,681 bytes ( 32.6%)

$
$ npm install google-closure-compiler terser uglifyjs-lite
$ curl -s -O https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.js
$ ./node_modules/.bin/google-closure-compiler jquery.js > 
jquery.min.google-closure-compiler.js 2>/dev/null
$ ./node_modules/.bin/terser jquery.js > jquery.min.terser.js 2>/dev/null
$ ./node_modules/.bin/uglifyjs-lite jquery.js > jquery.min.uglifyjs-lite.js 
2>/dev/null
$ ls -lS
total 1184
-rw-r--r--   1 kaizhu  wheel  271751 Feb 12 23:40 jquery.js
-rw-r--r--   1 kaizhu  wheel  137538 Feb 12 23:40 jquery.min.terser.js
-rw-r--r--   1 kaizhu  wheel   89845 Feb 12 23:40 
jquery.min.google-closure-compiler.js
-rw-r--r--   1 kaizhu  wheel   88681 Feb 12 23:40 jquery.min.uglifyjs-lite.js
-rw-r--r--   1 kaizhu  wheel   10563 Feb 12 22:59 package-lock.json
drwxr-xr-x  37 kaizhu  wheel1258 Feb 12 23:40 node_modules
$ 

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

Re: add stage4 constraint - ease-of-minification

[kai zhu]

> npm google-closure-compiler handles transpilation and minifiction.
> and it's just 2 deps, itself, and Java.
> https://www.npmjs.com/package/google-closure-compiler 
> 
hmm, google-closure-compiler actually has 29 dependencies (57mb total)


$ shNpmPackageDependencyTreeCreate google-closure-compiler

+ google-closure-compiler@20190121.0.0
added 29 packages from 72 contributors and audited 34 packages in 2.04s
found 0 vulnerabilities

[MODE_BUILD=npmPackageDependencyTree] - 2019-02-13T02:53:32.614Z - (shRun npm 
ls 2>&1)

/private/tmp/npmPackageDependencyTreeCreate
└─┬ google-closure-compiler@20190121.0.0
  ├─┬ chalk@1.1.3
  │ ├── ansi-styles@2.2.1
  │ ├── escape-string-regexp@1.0.5
  │ ├─┬ has-ansi@2.0.0
  │ │ └── ansi-regex@2.1.1
  │ ├─┬ strip-ansi@3.0.1
  │ │ └── ansi-regex@2.1.1 deduped
  │ └── supports-color@2.0.0
  ├── google-closure-compiler-java@20190121.0.0
  ├── google-closure-compiler-js@20190121.0.0
  ├── UNMET OPTIONAL DEPENDENCY google-closure-compiler-linux@20190121.0.0
  ├── google-closure-compiler-osx@20190121.0.0
  ├── minimist@1.2.0
  ├─┬ vinyl@2.2.0
  │ ├── clone@2.1.2
  │ ├── clone-buffer@1.0.0
  │ ├── clone-stats@1.0.0
  │ ├─┬ cloneable-readable@1.1.2
  │ │ ├── inherits@2.0.3
  │ │ ├── process-nextick-args@2.0.0
  │ │ └─┬ readable-stream@2.3.6
  │ │   ├── core-util-is@1.0.2
  │ │   ├── inherits@2.0.3 deduped
  │ │   ├── isarray@1.0.0
  │ │   ├── process-nextick-args@2.0.0 deduped
  │ │   ├── safe-buffer@5.1.2
  │ │   ├─┬ string_decoder@1.1.1
  │ │   │ └── safe-buffer@5.1.2 deduped
  │ │   └── util-deprecate@1.0.2
  │ ├── remove-trailing-separator@1.1.0
  │ └── replace-ext@1.0.0
  └─┬ vinyl-sourcemaps-apply@0.2.1
└── source-map@0.5.7

$ du -ms .
57  .




terser is relatively smaller with 5 dependencies (6mb total).  i might look 
into forking it and merge its dependencies into a standalone-package


$ shNpmPackageDependencyTreeCreate terser

+ terser@3.16.1
added 5 packages from 38 contributors and audited 6 packages in 1.742s
found 0 vulnerabilities

[MODE_BUILD=npmPackageDependencyTree] - 2019-02-13T02:54:10.589Z - (shRun npm 
ls 2>&1)

/private/tmp/npmPackageDependencyTreeCreate
└─┬ terser@3.16.1
  ├── commander@2.17.1
  ├── source-map@0.6.1
  └─┬ source-map-support@0.5.10
├── buffer-from@1.1.1
└── source-map@0.6.1 deduped

$ du -ms .
6   .


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

Re: add stage4 constraint - ease-of-minification

[kai zhu]

sorry that came out wrong, but i'm generally uncomfortable with the dearth
of reliable/correct es6+ compliant minifiers.  and i feel its an
industry-concern which slows product-development.

On Tue, Feb 12, 2019 at 6:35 PM kai zhu  wrote:

> Yes, exactly. minification-tooling is a real-concern for any
> consumer-facing javascript-product, and not all of them want to rely on
> babel.
>
> Are you arguing all new javascript-products should be coerced to integrate
> with babel, because it has a monopoly on such critical-tooling?
>
> On Tue, Feb 12, 2019 at 6:28 PM Jordan Harband  wrote:
>
>> So effectively, you're arguing that stagnant tools should hold back
>> evolution of the language, even when non-stagnant alternatives exist?
>>
>> On Tue, Feb 12, 2019 at 3:26 PM kai zhu  wrote:
>>
>>> > Can you expand on what you mean by this, or provide an example of a
>>> > feature that can't be "easily minified”?
>>>
>>> fat-arrow/destructuring/es6-classes comes to mind.  if you have legacy
>>> build-chain that doesn't use babel or terser, is it worth the effort to
>>> retool the minifier to support these syntaxes so you can use it?  also any
>>> feature which introduce new symbol/symbol-combo which requires re-auditing
>>> minifier's regexp-detection (private-fields, optional-chaining, etc.).
>>>
>>> there’s also the argument using babel in minification-toolchain defeats
>>> the purpose of reducing code-size.
>>>
>>> > On 12 Feb 2019, at 4:02 PM, Tab Atkins Jr. 
>>> wrote:
>>> >
>>> > On Tue, Feb 12, 2019 at 7:44 AM kai zhu  wrote:
>>> >> i think there’s an industry-painpoint (at least from my experience),
>>> of resistance adopting es6+ features because legacy-toolchains cannot be
>>> easily retooled to minify them.
>>> >>
>>> >> i’m not sure the best way to address this problem? i favor requiring
>>> 2 independent minifiers to be able to handle a stage3-proposal before
>>> advancement (indicating retooling is feasible), but that may be
>>> overly-restrictive to some folks.
>>> >
>>> > Can you expand on what you mean by this, or provide an example of a
>>> > feature that can't be "easily minified"?
>>> >
>>> > ~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: add stage4 constraint - ease-of-minification

[kai zhu]

Yes, exactly. minification-tooling is a real-concern for any
consumer-facing javascript-product, and not all of them want to rely on
babel.

Are you arguing all new javascript-products should be coerced to integrate
with babel, because it has a monopoly on such critical-tooling?

On Tue, Feb 12, 2019 at 6:28 PM Jordan Harband  wrote:

> So effectively, you're arguing that stagnant tools should hold back
> evolution of the language, even when non-stagnant alternatives exist?
>
> On Tue, Feb 12, 2019 at 3:26 PM kai zhu  wrote:
>
>> > Can you expand on what you mean by this, or provide an example of a
>> > feature that can't be "easily minified”?
>>
>> fat-arrow/destructuring/es6-classes comes to mind.  if you have legacy
>> build-chain that doesn't use babel or terser, is it worth the effort to
>> retool the minifier to support these syntaxes so you can use it?  also any
>> feature which introduce new symbol/symbol-combo which requires re-auditing
>> minifier's regexp-detection (private-fields, optional-chaining, etc.).
>>
>> there’s also the argument using babel in minification-toolchain defeats
>> the purpose of reducing code-size.
>>
>> > On 12 Feb 2019, at 4:02 PM, Tab Atkins Jr. 
>> wrote:
>> >
>> > On Tue, Feb 12, 2019 at 7:44 AM kai zhu  wrote:
>> >> i think there’s an industry-painpoint (at least from my experience),
>> of resistance adopting es6+ features because legacy-toolchains cannot be
>> easily retooled to minify them.
>> >>
>> >> i’m not sure the best way to address this problem? i favor requiring 2
>> independent minifiers to be able to handle a stage3-proposal before
>> advancement (indicating retooling is feasible), but that may be
>> overly-restrictive to some folks.
>> >
>> > Can you expand on what you mean by this, or provide an example of a
>> > feature that can't be "easily minified"?
>> >
>> > ~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: add stage4 constraint - ease-of-minification

[kai zhu]

> Can you expand on what you mean by this, or provide an example of a
> feature that can't be "easily minified”?

fat-arrow/destructuring/es6-classes comes to mind.  if you have legacy 
build-chain that doesn't use babel or terser, is it worth the effort to retool 
the minifier to support these syntaxes so you can use it?  also any feature 
which introduce new symbol/symbol-combo which requires re-auditing minifier's 
regexp-detection (private-fields, optional-chaining, etc.).

there’s also the argument using babel in minification-toolchain defeats the 
purpose of reducing code-size.

> On 12 Feb 2019, at 4:02 PM, Tab Atkins Jr.  wrote:
> 
> On Tue, Feb 12, 2019 at 7:44 AM kai zhu  wrote:
>> i think there’s an industry-painpoint (at least from my experience), of 
>> resistance adopting es6+ features because legacy-toolchains cannot be easily 
>> retooled to minify them.
>> 
>> i’m not sure the best way to address this problem? i favor requiring 2 
>> independent minifiers to be able to handle a stage3-proposal before 
>> advancement (indicating retooling is feasible), but that may be 
>> overly-restrictive to some folks.
> 
> Can you expand on what you mean by this, or provide an example of a
> feature that can't be "easily minified"?
> 
> ~TJ

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

add stage4 constraint - ease-of-minification

[kai zhu]

i think there’s an industry-painpoint (at least from my experience), of 
resistance adopting es6+ features because legacy-toolchains cannot be easily 
retooled to minify them.

i’m not sure the best way to address this problem? i favor requiring 2 
independent minifiers to be able to handle a stage3-proposal before advancement 
(indicating retooling is feasible), but that may be overly-restrictive to some 
folks.

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

Re: A way to fire logic at the end of completion of the current class method (regardless of super call order).

[kai zhu]

> I feel ES classes are overly restrictive in preventing
> this, since it basically forces you to force subclasses to do
> something like `this.init()` right after the class is allocated,
> leaking implementation details left and right.

its not a design-flaw.  the flaw is you trying to shoehorn “classical” 
inheritance-based design-patterns on a language better suited to use 
static-functions to baton-pass json-data (over class-instance).

here’s a real-world example of a ```dbTableCreateOne``` static-function to 
initialize a mongo-like collection/table, and then sync it with indexeddb 
persistence-store [1].  imagine how much more difficult these [common-case] 
async-initializations would be using inheritance-based constructors.

```javascript
local.dbTableCreateOne = function (options, onError) {
/*
 * this function will create a dbTable with the given options
 */
var self;
options = local.objectSetOverride(options);
// register dbTable
self = local.dbTableDict[options.name] =
local.dbTableDict[options.name] || new local._DbTable(options);
...
// restore dbTable from persistent-storage
self.isLoaded = self.isLoaded || options.isLoaded;
if (!self.isLoaded) {
local.storageGetItem('dbTable.' + self.name + '.json', function (error, 
data) {
// validate no error occurred
local.assert(!error, error);
if (!self.isLoaded) {
local.dbImport(data);
}
self.isLoaded = true;
local.setTimeoutOnError(onError, 0, null, self);
});
return self;
}
return local.setTimeoutOnError(onError, 0, null, self);
};
```

p.s. - going off-topic, but above-mentioned code/library (as well as proposals 
for standard tree/stl libraries) shouldn’t even exist if javascript had a 
builtin/standard sqlite3 library (like python).

[1] initialize a db-table and sync it with persistence-store
https://github.com/kaizhu256/node-db-lite/blob/2018.4.23/lib.db.js#L1861 


[2] discuss including tree and stl in proposed standard-library
https://github.com/tc39/proposal-javascript-standard-library/issues/16#issuecomment-457833409
 

https://github.com/tc39/proposal-javascript-standard-library/issues/16#issuecomment-461285304
 

> On 9 Feb 2019, at 4:18 AM, Isiah Meadows  wrote:
> 
> I've also had *several* scenarios where I could've used this
> personally. I feel ES classes are overly restrictive in preventing
> this, since it basically forces you to force subclasses to do
> something like `this.init()` right after the class is allocated,
> leaking implementation details left and right.
> 
> -
> 
> Isiah Meadows
> cont...@isiahmeadows.com
> www.isiahmeadows.com
> 
> On Fri, Feb 8, 2019 at 1:22 AM #!/JoePea  wrote:
>> 
>> I many times find myself in cases where a base class wants to ensure that 
>> logic is always fired after the current method's execution, so that for 
>> example no matter in which order sub classes call the `super` method, the 
>> `super` method can still guarantee that logic fires after the whole stack of 
>> the same method in the class hierarchy.
>> 
>> So what I can do now is use `Promise.resolve().then(() => { ... })` to 
>> schedule that logic for later, that way all the invocations of a `foo` 
>> method along the class hierarchy have all fired. But this means that other 
>> code can also fire before the next microtask.
>> 
>> Is there some way to do it? If not, I wonder if some language feature for 
>> doing it would be possible?
>> 
>> - Joe
>> ___
>> 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: Introspect bind function targets

[kai zhu]

> for (var i = 0; i < 10; i++) {
>foo({ handleClick: () => {} })
> }

your ux-workflow example of creating multiple, closure-bound handleClick's is 
wasteful, and more complicated than needs be.  the correct design-pattern is to 
delegate it with a single handClickDelegated (and figure out context from 
event.target.dataset) [1]

```html
button #1
button #2
button #3

/*jslint browser, devel*/
(function () {
"use strict";
var handleClickDelegated;
handleClickDelegated = function (event) {
document.body.innerHTML += (
"
clicked button #"
+ event.target.dataset.propIi
+ "
"
);
};
document.body.addEventListener("click", handleClickDelegated);
}());

```

[1] https://codepen.io/kaizhu256/pen/xMLvzX


> On 5 Feb 2019, at 5:50 AM, Sultan Tarimo  wrote:
> 
> For example given a set of values. A function that checks whether the values 
> of the object are equal could shallow compare the values of each property in 
> the object. However this heuristics falls short for inline/bound functions 
> that share the same target/backing but are only different with respect to the 
> function “objects" equality.
> 
> Consider the following:
> 
> function foo (props) {
>return shallowCompare(props) ? expensiveOperation(props) : 
> memorizedOperation(props)
> }
> 
> for (var i = 0; i < 10; i++) {
>foo({ handleClick: () => {} })
> }
> 
> The function `handleClick` passed to “foo” always points to the same function 
> target even though the closure object passed may be different on each 
> iteration.
> 
> Function.isSameTarget(a, b)
> 
> Would expose some level of introspection to identify when the function is 
> either a bound function referencing the same function target or a closure 
> object referencing the same function target.
> 
> This would also allow things like:
> 
> class A {fn = () => {}}
> 
> Function.isSameTarget((new A).fn, (new A).fn) 
> ___
> 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: RegExp.prototype.count

[kai zhu]

+1 for string.count

i don’t think the g-flag is necessary in str.split, so the original performance 
claims are still valid:
- for counting regexp - use split + length
- for counting substring - use while + indexOf

> On 20 Jan 2019, at 12:22 AM, Isiah Meadows  wrote:
> 
> Nit: you should use `.spilt(/\n/g)` to get all parts.
> 
> I like the benchmarks here. That's much appreciated, and after further
> investigation, I found a *giant* WTF:
> https://jsperf.com/regexp-counting-2/8
> 
> TL;DR: for string character counting, prefer `indexOf`.
> 
> For similar reasons to that JSPerf thing, I'd like it to be on the
> String prototype rather than the RegExp prototype, as in
> `str.count(/\n/)`.
> 
> -
> 
> Isiah Meadows
> cont...@isiahmeadows.com
> www.isiahmeadows.com
> 
> On Sun, Jan 20, 2019 at 12:33 AM kai zhu  wrote:
>> 
>> benchmarked @isiah’s while-loop test-case vs str.split vs str.replace for 
>> regexp counting on jsperf.com [1], and the results were surprising (for me).
>> 
>> benchmarks using 1mb random ascii-string from fastest to slowest.
>> 1. (fastest - 1,700 runs/sec) regexp-counting with 
>> ```largeCode.split(/\n/).length - 1```
>> 2. (40% slower - 1000 runs/sec) regexp-counting with ```while-loop (/n/g)```
>> 3. (60% slower - 700 runs/sec) regexp-counting with 
>> ```largeCode.replace((/[^\n]+/g), "").length```
>> 
>> looks like the go-to design-pattern for counting-regexp is 
>> ```str.split().length - 1```
>> 
>> [1] regexp counting 2
>> https://jsperf.com/regexp-counting-2
>> 
>> On 13 Jan 2019, at 9:15 PM, Isiah Meadows  wrote:
>> 
>> If performance is an issue, regular expressions are likely to be too slow to 
>> begin with. But you could always do this to count the number of lines in a 
>> particular string:
>> 
>> ```js
>> var count = 0
>> var re = /\n|\r\n?/g
>> while (re.test(str)) count++
>> console.log(count)
>> ```
>> 
>> Given it's already this easy to iterate something with a regexp, I'm not 
>> convinced it's necessary to add this property/method.
>> On Sat, Jan 12, 2019 at 17:29 kai zhu  wrote:
>>> 
>>> a common use-case i have is counting newlines in largish (> 200kb) 
>>> embedded-js files, like this real-world example [1].  ultimately meant for 
>>> line-number-preservation purposes in auto-lint/auto-prettify tasks (which 
>>> have been getting slower due to complexity).
>>> 
>>> would a new RegExp count-method like ```(/\n/g).count(largeCode)``` be 
>>> significantly more efficient than existing ```largeCode.split("\n").length 
>>> - 1``` or ```largeCode.replace((/[^\n]+/g), "").length```?
>>> 
>>> -kai
>>> 
>>> [1] calculating and reproducing line-number offsets when linting/autofixing 
>>> files
>>> https://github.com/kaizhu256/node-utility2/blob/2018.12.30/lib.jslint.js#L7377
>>> https://github.com/kaizhu256/node-utility2/blob/2018.12.30/lib.jslint.js#L7586
>>> 
>>> ___
>>> 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: RegExp.prototype.count

[kai zhu]

benchmarked @isiah’s while-loop test-case vs str.split vs str.replace for 
regexp counting on jsperf.com <http://jsperf.com/> [1], and the results were 
surprising (for me).  

benchmarks using 1mb random ascii-string from fastest to slowest.
1. (fastest - 1,700 runs/sec) regexp-counting with 
```largeCode.split(/\n/).length - 1```
2. (40% slower - 1000 runs/sec) regexp-counting with ```while-loop (/n/g)```
3. (60% slower - 700 runs/sec) regexp-counting with 
```largeCode.replace((/[^\n]+/g), "").length```

looks like the go-to design-pattern for counting-regexp is 
```str.split().length - 1```

[1] regexp counting 2
https://jsperf.com/regexp-counting-2

> On 13 Jan 2019, at 9:15 PM, Isiah Meadows  wrote:
> 
> If performance is an issue, regular expressions are likely to be too slow to 
> begin with. But you could always do this to count the number of lines in a 
> particular string:
> 
> ```js
> var count = 0
> var re = /\n|\r\n?/g
> while (re.test(str)) count++
> console.log(count)
> ```
> 
> Given it's already this easy to iterate something with a regexp, I'm not 
> convinced it's necessary to add this property/method.
> On Sat, Jan 12, 2019 at 17:29 kai zhu  <mailto:kaizhu...@gmail.com>> wrote:
> a common use-case i have is counting newlines in largish (> 200kb) 
> embedded-js files, like this real-world example [1].  ultimately meant for 
> line-number-preservation purposes in auto-lint/auto-prettify tasks (which 
> have been getting slower due to complexity).
> 
> would a new RegExp count-method like ```(/\n/g).count(largeCode)``` be 
> significantly more efficient than existing ```largeCode.split("\n").length - 
> 1``` or ```largeCode.replace((/[^\n]+/g), "").length```?
> 
> -kai
> 
> [1] calculating and reproducing line-number offsets when linting/autofixing 
> files
> https://github.com/kaizhu256/node-utility2/blob/2018.12.30/lib.jslint.js#L7377
>  
> <https://github.com/kaizhu256/node-utility2/blob/2018.12.30/lib.jslint.js#L7377>
> https://github.com/kaizhu256/node-utility2/blob/2018.12.30/lib.jslint.js#L7586
>  
> <https://github.com/kaizhu256/node-utility2/blob/2018.12.30/lib.jslint.js#L7586>
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss 
> <https://mail.mozilla.org/listinfo/es-discuss>

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

Re: Proposal: [Symbol.equals]

[kai zhu]

> This thread would apply equally well to objects (there's no such thing as a 
> "json object" - json is a string, and once it's parsed into an object it's 
> not json anymore) as to classes.

i’m not so sure when you start having classes with 
getters/setters/private-fields.  then people begin digging rabbit-holes/silos 
trying to solve low-level equality-issues that shouldn’t even exist, and 
overall lose focus of the big-picture UX-workflow problems most of us js-devs 
were originally hired to solve.

> On 18 Jan 2019, at 11:32 PM, Jordan Harband  wrote:
> 
> This thread would apply equally well to objects (there's no such thing as a 
> "json object" - json is a string, and once it's parsed into an object it's 
> not json anymore) as to classes.
> 
> Please stop derailing threads with your off-topic ideology about how to write 
> code - that belongs in a style guide, or in your own project, but not here.
> 
> On Fri, Jan 18, 2019 at 9:28 PM kai zhu  <mailto:kaizhu...@gmail.com>> wrote:
> the most reliable/idiot-proof equality is by avoiding classes altogether; 
> stick with plain json-objects and compare their canonical-json-representation 
> like this real-world example [1]:
> 
> ```
> /*jslint devel*/
> (function () {
> "use strict";
> var jsonStringifyCanonical;
> 
> jsonStringifyCanonical = function (obj, replacer, space) {
> /*
>  * this function will JSON.stringify ,
>  * with object-keys sorted and circular-references removed
>  */
> var circularSet;
> var stringify;
> var tmp;
> stringify = function (obj) {
> /*
>  * this function will recursively JSON.stringify obj,
>  * with object-keys sorted and circular-references removed
>  */
> // if obj is not an object or function,
> // then JSON.stringify as normal
> if (!(
> obj
> && typeof obj === "object"
> && typeof obj.toJSON !== "function"
> )) {
> return JSON.stringify(obj);
> }
> // ignore circular-reference
> if (circularSet.has(obj)) {
> return;
> }
> circularSet.add(obj);
> // if obj is an array, then recurse its items
> if (Array.isArray(obj)) {
> tmp = "[" + obj.map(function (obj) {
> // recurse
> tmp = stringify(obj);
> return (
> typeof tmp === "string"
> ? tmp
> : "null"
> );
> }).join(",") + "]";
> circularSet.delete(obj);
> return tmp;
> }
> // if obj is not an array,
> // then recurse its items with object-keys sorted
> tmp = "{" + Object.keys(obj).sort().map(function (key) {
> // recurse
> tmp = stringify(obj[key]);
> if (typeof tmp === "string") {
> return JSON.stringify(key) + ":" + tmp;
> }
> }).filter(function (obj) {
> return typeof obj === "string";
> }).join(",") + "}";
> circularSet.delete(obj);
> return tmp;
> };
> circularSet = new Set();
> return JSON.stringify((
> (typeof obj === "object" && obj)
> // recurse
> ? JSON.parse(stringify(obj))
> : obj
> ), replacer, space);
> };
> 
> // true
> console.assert(
> // {"data":{"x":1,"y":2,"z":3},"meta":{"label":"point #13"}}
> jsonStringifyCanonical({
> data: {x: 1, y: 2, z: 3},
> meta: {label: "point #32"}
> })
> // === {"data":{"x":1,"y":2,"z":3},"meta":{"label":"point #13"}}
> === jsonStringifyCanonical({
> meta: {label: "point #32"},
> data: {z: 3, y: 2, x: 1}
> })
> );
> }());
> ```
> 
> 
> [1] testing aa “==“ b by comparing their canonical json-representation
> https://github.com/kaizhu256/node-utility2/blob/2018.12.30/test.js#L2903 
> <https://github.com/kaizhu256/node-utility2/blob/2018.12.30/tes

Re: Proposal: [Symbol.equals]

[kai zhu]

the most reliable/idiot-proof equality is by avoiding classes altogether; stick 
with plain json-objects and compare their canonical-json-representation like 
this real-world example [1]:

```
/*jslint devel*/
(function () {
"use strict";
var jsonStringifyCanonical;

jsonStringifyCanonical = function (obj, replacer, space) {
/*
 * this function will JSON.stringify ,
 * with object-keys sorted and circular-references removed
 */
var circularSet;
var stringify;
var tmp;
stringify = function (obj) {
/*
 * this function will recursively JSON.stringify obj,
 * with object-keys sorted and circular-references removed
 */
// if obj is not an object or function,
// then JSON.stringify as normal
if (!(
obj
&& typeof obj === "object"
&& typeof obj.toJSON !== "function"
)) {
return JSON.stringify(obj);
}
// ignore circular-reference
if (circularSet.has(obj)) {
return;
}
circularSet.add(obj);
// if obj is an array, then recurse its items
if (Array.isArray(obj)) {
tmp = "[" + obj.map(function (obj) {
// recurse
tmp = stringify(obj);
return (
typeof tmp === "string"
? tmp
: "null"
);
}).join(",") + "]";
circularSet.delete(obj);
return tmp;
}
// if obj is not an array,
// then recurse its items with object-keys sorted
tmp = "{" + Object.keys(obj).sort().map(function (key) {
// recurse
tmp = stringify(obj[key]);
if (typeof tmp === "string") {
return JSON.stringify(key) + ":" + tmp;
}
}).filter(function (obj) {
return typeof obj === "string";
}).join(",") + "}";
circularSet.delete(obj);
return tmp;
};
circularSet = new Set();
return JSON.stringify((
(typeof obj === "object" && obj)
// recurse
? JSON.parse(stringify(obj))
: obj
), replacer, space);
};

// true
console.assert(
// {"data":{"x":1,"y":2,"z":3},"meta":{"label":"point #13"}}
jsonStringifyCanonical({
data: {x: 1, y: 2, z: 3},
meta: {label: "point #32"}
})
// === {"data":{"x":1,"y":2,"z":3},"meta":{"label":"point #13"}}
=== jsonStringifyCanonical({
meta: {label: "point #32"},
data: {z: 3, y: 2, x: 1}
})
);
}());
```


[1] testing aa “==“ b by comparing their canonical json-representation
https://github.com/kaizhu256/node-utility2/blob/2018.12.30/test.js#L2903 

https://github.com/kaizhu256/node-utility2/blob/2018.12.30/lib.utility2.js#L2760
 



> On 18 Jan 2019, at 3:39 PM, Isiah Meadows  wrote:
> 
> Yeah, I agree. I'd suggest overloading `==`, but that'd risk serious web 
> compat issues, especially if `null`/`undefined` aren't special-cased. I feel 
> an `equals` instance method added to all builtins and an `Object.equals` 
> attempting that method first before performing a shallow object comparison 
> would be the best solution.
> On Fri, Jan 18, 2019 at 15:24 Jordan Harband  > wrote:
> It's pretty important that the meaning `===` not be able to change.
> 
> On Fri, Jan 18, 2019 at 10:33 AM ViliusCreator  > wrote:
> What about having Symbol.equals?
> 
> For example, for now this is what it does:
> 
> ```js
> 
> class Position { 
> constructor(o) {
> this.x = o.x instanceof Number ? o.x : 0
> 
> this.y = o.y instanceof Number ? o.y : 0
> 
> this.z = o.z instanceof Number ? o.z : 0
> }
> }
> console.log(new Position({x: 10, y: 10, z: 10}) === new Position({x: 10, y: 
> 10, z: 10})
> 
> ```
> Output is of course, false.
> With `Symbol.equals`, we could make it easier, instead of 
> `instance.equals(otherInstance)`.
> 
>  
> 
> For example:
> 
> ```js
> 
> class Position {
> 
> [Symbol.equals](oIn) {
> return oIn.x === this.x && oIn.y === this.y && oIn.z === this.z
> }
> constructor(o) {
> this.x = o.x instanceof Number ? o.x : 0
> 
> this.y = o.y instanceof Number ? o.y : 0
> 
> this.z = o.z instanceof Number ? o.z : 0
> }
> }
> console.log(new Position({x: 10, y: 10, z: 10}) === new Position({x: 10, y: 
> 10, z: 10})
> 
> ```
> Now output would be true.
> 
> This would save most of 

RegExp.prototype.count

[kai zhu]

a common use-case i have is counting newlines in largish (> 200kb) embedded-js 
files, like this real-world example [1].  ultimately meant for 
line-number-preservation purposes in auto-lint/auto-prettify tasks (which have 
been getting slower due to complexity).

would a new RegExp count-method like ```(/\n/g).count(largeCode)``` be 
significantly more efficient than existing ```largeCode.split("\n").length - 
1``` or ```largeCode.replace((/[^\n]+/g), "").length```?

-kai

[1] calculating and reproducing line-number offsets when linting/autofixing 
files
https://github.com/kaizhu256/node-utility2/blob/2018.12.30/lib.jslint.js#L7377 

https://github.com/kaizhu256/node-utility2/blob/2018.12.30/lib.jslint.js#L7586 


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

Re: String identity template tag

[kai zhu]

*everything* using javascript is ultimately meant to solve a UX-workflow
problem (including js-code in servers, IoT, satellites, etc.).  if you're
so caught up in low-level js library-code that you can't see how the piece
fits/integrates into that big-picture, then you should go back to
general-purpose programming in java/c++/c#/etc.

but of course, much of industry these days prefer hiring business-oriented
programmers focused on solving UX-workflow problems rather than
general-purpose programming ones.



On Wed, Dec 19, 2018 at 6:52 AM Isiah Meadows 
wrote:

> Could you bring that up in a different thread instead of driving this
> off-topic? Also, please don't forget that a *very* significant chunk
> of JS doesn't even run in a GUI environment (consider: servers, IoT,
> satellites, etc.).
>
> -
>
> Isiah Meadows
> cont...@isiahmeadows.com
> www.isiahmeadows.com
>
> On Wed, Dec 19, 2018 at 1:33 AM kai zhu  wrote:
> >>
> >> I could go with an iterator equivalent, but I'd like to defer that to
> >> the seemingly-planned "iterlib" thing that's been considered since
> >> before ES2015 was released.
> >
> >
> > i'm against iterator-based design-patterns and libraries, as they lack a
> clear fit in most javascript solutions.  the vast majority of looping in
> UX-workflows (javascript’s primary problem-domain) are over [serializable]
> JSON lists/dicts/strings, where Array/Object/String looping-methods will
> suffice.
> >
> > all other use-cases are uncommon/complicated enough that custom
> for/while loops are usually better suited than custom-iterators.
> >
> > -kai
> >
> >
> >
> > On 18 Dec 2018, at 16:42, Mike Samuel  wrote:
> >
> > Fair enough.
> >
> > On Tue, Dec 18, 2018, 5:29 PM Isiah Meadows  wrote:
> >>
> >> I could go with an iterator equivalent, but I'd like to defer that to
> >> the seemingly-planned "iterlib" thing that's been considered since
> >> before ES2015 was released. Something that works with arrays is good
> >> enough for now.
> >>
> >> BTW, your `ziperator` isn't really the same as my `Array.interpolate`
> >> (which is better named `Array.interleave`). It needs to be this:
> >>
> >> ```js
> >> function *ziperator(...iters) {
> >> for (let i = 0; i < iters.length; i++) {
> >> iters[i] = iters[i][Symbol.iterator]()
> >> }
> >> while (true) {
> >> for (let i = 0; i < iters.length; i++) {
> >> const {done, value} = iters[i].next()
> >> if (done) return undefined
> >> yield value
> >> }
> >> }
> >> }
> >> ```
> >>
> >> The optimized version is pretty straightforward (using private fields
> >> + methods here):
> >>
> >> ```js
> >> function ziperator(...iters) { return new InterleavedIterator(iters) }
> >>
> >> class InterleavedIterator {
> >> #iters, #index
> >> constructor(iters) { this.#iters = iters; this.#index = 0 }
> >> [Symbol.iterator]() { return this }
> >> next(value) { return this.#invoke("next", value) }
> >> throw(value) { return this.#invoke("throw", value) }
> >> return(value) { return this.#invoke("return", value) }
> >> #invoke(method, value) {
> >> if (this.#iters == null) return {done: true, value: undefined}
> >> const index = this.#index
> >> this.#index = (index + 1) % this.#iters.length
> >> const {done, value} = this.#iters[index][method](value)
> >> if (done) this.#iters = undefined
> >> return {done, value}
> >> }
> >> }
> >> ```
> >>
> >> -
> >>
> >> Isiah Meadows
> >> cont...@isiahmeadows.com
> >> www.isiahmeadows.com
> >> On Fri, Dec 14, 2018 at 2:55 PM Mike Samuel 
> wrote:
> >> >
> >> >
> >> >
> >> > On Fri, Dec 14, 2018 at 2:26 PM Isiah Meadows 
> wrote:
> >> >>
> >> >> The main difference with that loop is that it's generalized to any
> number of arrays, not just two with the second array having length one less
> than the first. Otherwise, it'd look exactly the same. BTW, I like this
> route (`Array.interleave`) better since it doesn't have to result in just a
> single string result - it could just be an array of strings plugged into
> some API instead, or it could be procedurally streamed out i

Re: String identity template tag

[kai zhu]

> I could go with an iterator equivalent, but I'd like to defer that to
> the seemingly-planned "iterlib" thing that's been considered since
> before ES2015 was released.

i'm against iterator-based design-patterns and libraries, as they lack a clear 
fit in most javascript solutions.  the vast majority of looping in UX-workflows 
(javascript’s primary problem-domain) are over [serializable] JSON 
lists/dicts/strings, where Array/Object/String looping-methods will suffice.

all other use-cases are uncommon/complicated enough that custom for/while loops 
are usually better suited than custom-iterators.

-kai



> On 18 Dec 2018, at 16:42, Mike Samuel  wrote:
> 
> Fair enough.
> 
> On Tue, Dec 18, 2018, 5:29 PM Isiah Meadows   wrote:
> I could go with an iterator equivalent, but I'd like to defer that to
> the seemingly-planned "iterlib" thing that's been considered since
> before ES2015 was released. Something that works with arrays is good
> enough for now.
> 
> BTW, your `ziperator` isn't really the same as my `Array.interpolate`
> (which is better named `Array.interleave`). It needs to be this:
> 
> ```js
> function *ziperator(...iters) {
> for (let i = 0; i < iters.length; i++) {
> iters[i] = iters[i][Symbol.iterator]()
> }
> while (true) {
> for (let i = 0; i < iters.length; i++) {
> const {done, value} = iters[i].next()
> if (done) return undefined
> yield value
> }
> }
> }
> ```
> 
> The optimized version is pretty straightforward (using private fields
> + methods here):
> 
> ```js
> function ziperator(...iters) { return new InterleavedIterator(iters) }
> 
> class InterleavedIterator {
> #iters, #index
> constructor(iters) { this.#iters = iters; this.#index = 0 }
> [Symbol.iterator]() { return this }
> next(value) { return this.#invoke("next", value) }
> throw(value) { return this.#invoke("throw", value) }
> return(value) { return this.#invoke("return", value) }
> #invoke(method, value) {
> if (this.#iters == null) return {done: true, value: undefined}
> const index = this.#index
> this.#index = (index + 1) % this.#iters.length
> const {done, value} = this.#iters[index][method](value)
> if (done) this.#iters = undefined
> return {done, value}
> }
> }
> ```
> 
> -
> 
> Isiah Meadows
> cont...@isiahmeadows.com 
> www.isiahmeadows.com 
> On Fri, Dec 14, 2018 at 2:55 PM Mike Samuel  > wrote:
> >
> >
> >
> > On Fri, Dec 14, 2018 at 2:26 PM Isiah Meadows  > > wrote:
> >>
> >> The main difference with that loop is that it's generalized to any number 
> >> of arrays, not just two with the second array having length one less than 
> >> the first. Otherwise, it'd look exactly the same. BTW, I like this route 
> >> (`Array.interleave`) better since it doesn't have to result in just a 
> >> single string result - it could just be an array of strings plugged into 
> >> some API instead, or it could be procedurally streamed out in chunks.
> >
> >
> > Fair enough.
> > If you're not looking for something template tag specific then a simple zip 
> > over iterators should do it?
> >
> > function *ziperator(iterators) {
> > let progressed;
> > do {
> > progressed = false;
> > for (let iterator of iterators) {
> > for (let element of iterator) {
> > yield element;
> > progressed = true;
> > break;
> > }
> > }
> > } while (progressed);
> > }
> >
> > console.log(Array.from(ziperator([ ['a', 'b', 'c'][Symbol.iterator](), [1, 
> > 2][Symbol.iterator]() ])).join(''));
> > // -> a1b2c
> >
> > (but optimized :)
> >
> >
> >
> >>
> >> On Fri, Dec 14, 2018 at 14:04 Mike Samuel  >> > wrote:
> >>>
> >>>
> >>>
> >>> On Fri, Dec 14, 2018 at 12:51 PM Isiah Meadows  >>> > wrote:
> 
>  I'll point out Kai could be on to something, although I disagree `zip` 
>  would be the right abstraction. Maybe `Array.interleave(...arrays)`? You 
>  could do `Array.interleave(template, args).map(String).join("")` for 
>  similar effect, and it'd be more generally useful.
> 
>  The key here is that iteration would stop after the index hits any 
>  array's length, so it'd be polyfilled kinda like this:
> 
>  ```js
>  Array.interpolate = (...args) => {
>  let ret = []
>  let lengths = []
>  let count = 0
>  for (let i = 0; i < args.length; i++) {
>  lengths[i] = args[i].count
>  }
>  for (let index = 0; ; index++) {
>  for (let i = 0; i < args.length; i++) {
>  if (index === lengths[i]) return ret
>  ret[count++] = args[i][index]
> 

Re: String identity template tag

[kai zhu]

why not copy python's list-zip static-function (
https://www.programiz.com/python-programming/methods/built-in/zip)?

i'm also against the spread-operator signature.

```javascript
// python-inspired list-zip static-function
// List.zip(list1, list2)
str = List.zip(
templateList,
argList
// slice-out argList-padded undefined
).slice(0, -1).join("\n");



// List.zip only zips up to length of list1
// padding with undefined

List.zip([1, 2, 3], ["one", "two"]);
// [1, "one", 2, "two", 3, undefined]

List.zip([1, 2], ["one", "two", "three"]);
// [1, "one", 2, "two"]
```


On Thu, Dec 13, 2018, 04:15 T.J. Crowder 
wrote:

> In general, I think method names should be verbs in the imperative
> tense (okay, *mood* if you like linguistic distinctions), which would
> argue for `cook` rather than `cooked`. (`String.raw` is an unfortunate
> exception to this rule, which has largely been used throughout the
> standard library. Another exception is `Reflect.ownKeys`. There are
> probably others as well, but they are exceptions, not the norm.)
>
> I like `cook`. It's `assemble`, but with more flavor.
>
> The good news here, though, is we're all talking about a name, which
> suggests that in general people like the taste of the idea. There
> don't seem to be concerns that it's half-baked.
>
> (I'll stop now.)
>
> -- 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

Re: Proposal for faster this assignments in constructor functions

[kai zhu]

just to clarify, my previous -1 was to Augusto's decorator-suggestion.

but I'm against the the main proposal as well due extra cognitive-load of
decoding the "." prefix when debugging code not written by me.  I already
have readability problems with {...} brackets due to destructuring,
es-classes, and fat-arrows.

-kai


On Thu, Nov 29, 2018, 11:00 kai zhu  wrote:

> -1
>
> this makes the common javascript-painpoint of pinpointing bugs in
> UX-workflows even worse.
>
> you're getting invalid visualization or timeouts from the web-UI during
> integration/qa. maybe it's from a bug in following low-level code? if so,
> was bug from a) constructor, b) foo, or c) @field?
>
> > class Foo {
> >   constructor(@field foo) {
> >   }
> > }
> > var bar = new Foo(foo);
>
> this is also why i'm against decorators in general.  i've used them in
> python, and beyond toy-cases, it quickly becomes very confusing whether I
> should put my business-logic in the decorator or the function ... and pity
> to any poor-soul debugging my code trying to figure it out, or worse ends
> up having to refactor the decorator (without breaking any of the functions
> it touches).
>
> -kai
>
>
>
> On Thu, Nov 29, 2018, 07:33 Isiah Meadows  wrote:
>
>> Just dropping in real quick to correct a couple things.
>>
>> First, `arguments` itself is *not* deprecated in strict mode. Things
>> like `arguments.caller` are deprecated and throw a `TypeError` when
>> the corresponding function is in strict mode.
>>
>> Second, some of you all were looking to use `Object.assign` to help
>> explain. You'd need to do this for it to be correct:
>>
>> ```js
>> class C {
>> constructor(a, b, ..., y, z) {
>> Object.assign(this, {a, b, ..., y, z})
>> }
>> }
>> ```
>>
>> (Not TC39, just I felt the need to correct people here.)
>>
>> -
>>
>> Isiah Meadows
>> cont...@isiahmeadows.com
>> www.isiahmeadows.com
>> On Wed, Nov 28, 2018 at 5:50 PM Augusto Moura 
>> wrote:
>> >
>> > I forgot the links in my last email, here they are:
>> > [1] https://github.com/tc39/proposal-decorators
>> > [2]
>> https://docs.google.com/document/d/1Qpkqf_8NzAwfD8LdnqPjXAQ2wwh8BBUGynhn-ZlCWT0
>> > Em qua, 28 de nov de 2018 às 20:48, Augusto Moura
>> >  escreveu:
>> > >
>> > > In the ~maybe long~ future , after the current decorators proposal
>> [1], we can start thinking about a Method Parameter Decorator (already
>> proposed [2]), we could do something like:
>> > >
>> > > ``` js
>> > > class Foo {
>> > >   constructor(@field foo) {
>> > >   }
>> > > }
>> > > ```
>> > >
>> > > In my opinion, it would be a much more powerful approach
>> > > Em qua, 28 de nov de 2018 às 16:33, Simo Costa <
>> andrysimo1...@gmail.com> escreveu:
>> > > >
>> > > > In costructor functions and in the constructor() method in ES6
>> classes is easily to fall in the following pattern:
>> > > >
>> > > > F(par1, par2, ..., parN) {
>> > > >   this.par1 = par1;
>> > > >   this.par2 = par2;
>> > > >   ...
>> > > >   this.parN = parN;
>> > > > }
>> > > >
>> > > >
>> > > > So my proposal is to avoid those repetitions  by prefixing a dot .
>> to each parameter:
>> > > >
>> > > > F(.par1, .par2, ..., .parN) {}
>> > > >
>> > > > Simple but quite useful. More info here:
>> https://github.com/jfet97/proposal-fast-this-assignments
>> > > >
>> > > >
>> > > >
>> > > > ___
>> > > > es-discuss mailing list
>> > > > es-discuss@mozilla.org
>> > > > https://mail.mozilla.org/listinfo/es-discuss
>> > >
>> > >
>> > >
>> > > --
>> > > Atenciosamente,
>> > >
>> > > Augusto Borges de Moura
>> >
>> >
>> >
>> > --
>> > Atenciosamente,
>> >
>> > Augusto Borges de Moura
>> > ___
>> > 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 faster this assignments in constructor functions

[kai zhu]

-1

this makes the common javascript-painpoint of pinpointing bugs in
UX-workflows even worse.

you're getting invalid visualization or timeouts from the web-UI during
integration/qa. maybe it's from a bug in following low-level code? if so,
was bug from a) constructor, b) foo, or c) @field?

> class Foo {
>   constructor(@field foo) {
>   }
> }
> var bar = new Foo(foo);

this is also why i'm against decorators in general.  i've used them in
python, and beyond toy-cases, it quickly becomes very confusing whether I
should put my business-logic in the decorator or the function ... and pity
to any poor-soul debugging my code trying to figure it out, or worse ends
up having to refactor the decorator (without breaking any of the functions
it touches).

-kai



On Thu, Nov 29, 2018, 07:33 Isiah Meadows  wrote:

> Just dropping in real quick to correct a couple things.
>
> First, `arguments` itself is *not* deprecated in strict mode. Things
> like `arguments.caller` are deprecated and throw a `TypeError` when
> the corresponding function is in strict mode.
>
> Second, some of you all were looking to use `Object.assign` to help
> explain. You'd need to do this for it to be correct:
>
> ```js
> class C {
> constructor(a, b, ..., y, z) {
> Object.assign(this, {a, b, ..., y, z})
> }
> }
> ```
>
> (Not TC39, just I felt the need to correct people here.)
>
> -
>
> Isiah Meadows
> cont...@isiahmeadows.com
> www.isiahmeadows.com
> On Wed, Nov 28, 2018 at 5:50 PM Augusto Moura 
> wrote:
> >
> > I forgot the links in my last email, here they are:
> > [1] https://github.com/tc39/proposal-decorators
> > [2]
> https://docs.google.com/document/d/1Qpkqf_8NzAwfD8LdnqPjXAQ2wwh8BBUGynhn-ZlCWT0
> > Em qua, 28 de nov de 2018 às 20:48, Augusto Moura
> >  escreveu:
> > >
> > > In the ~maybe long~ future , after the current decorators proposal
> [1], we can start thinking about a Method Parameter Decorator (already
> proposed [2]), we could do something like:
> > >
> > > ``` js
> > > class Foo {
> > >   constructor(@field foo) {
> > >   }
> > > }
> > > ```
> > >
> > > In my opinion, it would be a much more powerful approach
> > > Em qua, 28 de nov de 2018 às 16:33, Simo Costa <
> andrysimo1...@gmail.com> escreveu:
> > > >
> > > > In costructor functions and in the constructor() method in ES6
> classes is easily to fall in the following pattern:
> > > >
> > > > F(par1, par2, ..., parN) {
> > > >   this.par1 = par1;
> > > >   this.par2 = par2;
> > > >   ...
> > > >   this.parN = parN;
> > > > }
> > > >
> > > >
> > > > So my proposal is to avoid those repetitions  by prefixing a dot .
> to each parameter:
> > > >
> > > > F(.par1, .par2, ..., .parN) {}
> > > >
> > > > Simple but quite useful. More info here:
> https://github.com/jfet97/proposal-fast-this-assignments
> > > >
> > > >
> > > >
> > > > ___
> > > > es-discuss mailing list
> > > > es-discuss@mozilla.org
> > > > https://mail.mozilla.org/listinfo/es-discuss
> > >
> > >
> > >
> > > --
> > > Atenciosamente,
> > >
> > > Augusto Borges de Moura
> >
> >
> >
> > --
> > Atenciosamente,
> >
> > Augusto Borges de Moura
> > ___
> > 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: Numeric Array prototypes

[kai zhu]

sorry for derailing, i just have many tooling/operational gripes on es6
(and reminding of past mistakes so they're not repeated is not necessarily
bad thing).

but yea max, min, mean (and maybe sumOfSquares), are common-enough
array-tasks they would be useful as optimized (maybe also
numerically-stable) built-in methods.

On Thu, Nov 22, 2018, 12:12 Jordan Harband  wrote:

> Python and JSLint aren't in any way the arbiters of what's idiomatic in
> JS; webpack is not a minifier, it's a bundler; I believe uglify-es exists,
> but most people use babel and uglify, in my experience, which work fine.
>
> Please don't derail this thread about numeric methods on array prototypes
> with complaints about the spread operator, thanks.
>
> On Wed, Nov 21, 2018 at 9:48 PM kai zhu  wrote:
>
>> @gbadebo, no he's talking about vectorized operations in c++ or whatever
>> native-language the js-engine is implemented in.
>>
>> the spread operator was a mistake. it's redundant to Object.p.apply
>> (violates python/jslint maxim of one-way of doing things), the syntax
>> increases cost of maintaining minifiers (for those who dislike webpack's
>> monopoly, and prefer zero-config, zero-dependency alternatives like
>> [classic] uglifyjs), and has performance footguns like the one mentioned by
>> @tj.
>>
>> On Thu, Nov 22, 2018, 10:51 Gbadebo Bello 
>> wrote:
>>
>>> >An advantage to having this an internal primitive is you can use
>>> vector instructions to check 4-8 values in parallel and then end with a
>>> final step of finding the max/min value of the vector. (integers can just
>>> use bit hacks, float max/min has hardware acceleration).
>>>
>>>
>>> I don't quite understand, does javascript now support vectorised
>>> operations on the client side or an external library would be needed for
>>> this?
>>>
>>> On Thu, Nov 22, 2018, 03:26 Gbadebo Bello 
>>> wrote:
>>>
>>>> Well, you are right. The `apply` method might not be the
>>>> best(Performance wise).
>>>>
>>>> @T.J. Crowder. Wow, my mind didn't go to `reduce` at all, I don't have
>>>> any issues with it, in fact I feel it would perform better than `apply`
>>>>
>>> ___
>>> 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: Numeric Array prototypes

[kai zhu]

@gbadebo, no he's talking about vectorized operations in c++ or whatever
native-language the js-engine is implemented in.

the spread operator was a mistake. it's redundant to Object.p.apply
(violates python/jslint maxim of one-way of doing things), the syntax
increases cost of maintaining minifiers (for those who dislike webpack's
monopoly, and prefer zero-config, zero-dependency alternatives like
[classic] uglifyjs), and has performance footguns like the one mentioned by
@tj.

On Thu, Nov 22, 2018, 10:51 Gbadebo Bello  wrote:

> >An advantage to having this an internal primitive is you can use vector
> instructions to check 4-8 values in parallel and then end with a final step
> of finding the max/min value of the vector. (integers can just use bit
> hacks, float max/min has hardware acceleration).
>
>
> I don't quite understand, does javascript now support vectorised
> operations on the client side or an external library would be needed for
> this?
>
> On Thu, Nov 22, 2018, 03:26 Gbadebo Bello 
> wrote:
>
>> Well, you are right. The `apply` method might not be the best(Performance
>> wise).
>>
>> @T.J. Crowder. Wow, my mind didn't go to `reduce` at all, I don't have
>> any issues with it, in fact I feel it would perform better than `apply`
>>
> ___
> 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: Cascade operator proposal — native fluent interfaces

[kai zhu]

quick PSA:

jslint recently (2018-09-27) added warning against "." delimited, per-line
method-chaining [1]

```javascript
/*jslint node*/
"use strict";
var str = "hello world";

// jslint - no warnings
console.log(
str.replace(
"hello",
"goodbye"
).replace(
"world",
"john"
).toUpperCase()
);

// jslint - warnings against "." delimited, per-line method-chaining
console.log(
str
// Unexpected space between 'str' and '.'.
.replace("hello", "goodbye")
// Unexpected space between ')' and '.'.
.replace("world", "john")
// Unexpected space between ')' and '.'.
.toUpperCase()
);
```

[1] jslint commit 2018-09-27 - warn against per-line method-chaining
https://github.com/douglascrockford/JSLint/commit/752c82d860ac14d35d492dc5c6ad0a0ed8227e76#diff-01d3d81a6eb6d82af3c377b55dc4fa28L4692

[image: Screen Shot 2018-11-13 at 11.06.26 AM.jpg]

On Tue, Nov 13, 2018 at 3:33 AM Michael Haufe 
wrote:

> It didn't survive the github migration AFAICT. There is no proposal listed
> on the repo.
>
>
> https://web.archive.org/web/20141214124428/http://wiki.ecmascript.org/doku.php?id=strawman:batch_assignment_operator
>
> https://esdiscuss.org/topic/batch-assignment-functions
>
>
> https://github.com/rwaldron/tc39-notes/blob/master/es6/2012-05/may-23.md#moustache
>
> On Mon, Nov 12, 2018 at 7:31 AM Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> I have a dejavu ... a similar proposal was rejected a while ago.
>>
>> Can't remember its name but it was like:
>>
>> ```js
>> foo.{
>>   a.b = c;
>>   d();
>> }
>> ```
>>
>> how is this different, if it's actually any different?
>>
>>
>> On Mon, Nov 12, 2018 at 2:23 PM T.J. Crowder <
>> tj.crow...@farsightsoftware.com> wrote:
>>
>>> On Sat, Nov 10, 2018 at 5:49 PM Timothy Johnson
>>>  wrote:
>>>
>>> It's **great** to see a proposal backed by an example implementation. :-)
>>>
>>> I suggest adding some explanation to the proposal about how your example
>>> knows the `..d()` applies to `foo` and not to `c`. From the Dart
>>> documentation, I'd *guess* (not being a Dart person) that it's because
>>> you'd need parens around the `c..d()` to force it to apply to that instead,
>>> but... More about the specific mechanics of that as it applies to JS would
>>> be useful.
>>>
>>> Probably also worth a one-liner that you're aware of and have allowed
>>> for how this relates to numeric literals (e.g.,
>>> `console.log(12..toString())`). I can see in your commit on the Babel fork
>>> that you have allowed for it, but for those who don't dig that deep...
>>>
>>> If this were in the language, I'd happily use it. I don't really feel
>>> the lack of it, though.
>>>
>>> -- 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
>>
> ___
> 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

stability of javascript design-patterns for dictionary-based compression

[kai zhu]

there's a discussion to web-standardize zstandard-compression, which digressed 
somewhat on javascript language-stability [1].  they want to improve 
performance over existing zlib using context-specific js/html/css/etc 
dictionaries.  however, the primary author of zstandard [and lz4] laments that 
over a 10-year span studying [albeit small number of] websites, there were no 
stable design-patterns suitable for “permanent” dictionaries (not just js, but 
html and everything else as well).  anyway, he provided snippet of keys used in 
the current js-dictionary, which i found interesting and wanted to share:

js:
return true;
return false}
Number.isInteger
d.type="text/javascript";
which is licensed under the Apache License, Version 2.0 */
window.console&


[1] stability of javascript design-patterns for dictionary-based compression
https://github.com/mozilla/standards-positions/issues/105#issuecomment-431198830

kai zhu
kaizhu...@gmail.com



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

Re: Deep spread operator (Bilal Abdullah)

[kai zhu]

digressing a bit, but once you get used to the idea of deep-copying objects 
using JSON.parse(JSON.stringify(x)), you also realize web-projects are alot 
simpler if you keep many non-JSON-datatypes in string-form by default (BigInt, 
Date, CivilXxx, etc.), since the use-case to copy/serialize data between 
web-components is far more common than the need to actually revive data for use 
in low-level business-logic.

kai zhu
kaizhu...@gmail.com



> On 24 Oct 2018, at 2:22 AM, Jamie  wrote:
> 
> 4 dots is already valid syntax when it has a number after it
> 
> let o = { 4 }
> 
> 
> On Tue, Oct 23, 2018 at 9:05 AM kai zhu  <mailto:kaizhu...@gmail.com>> wrote:
> hi Bilai, there’s no reliable way to deep-copy arbitrary js-objects. the most 
> practical “general” solution is two-step:
> 
> 1. deep-copy JSON-data first, e.g. ```var bb = 
> JSON.parse(JSON.stringify(aa))```
> 2. custom-copy non-JSON-data in a second-pass, e.g. ```bb.innerObj.func = 
> aa.innerObj.func```
> 
> like this real-world example [1]:
> 
> ```javascript
> local.jsonCopy = function (obj) {
> /*
>  * this function will [JSON] deep-copy obj
>  */
> return obj === undefined
> ? undefined
> : JSON.parse(JSON.stringify(obj));
> };
> ...
> // update apiDict
> self = local.apiDict[key.join('.')] = local.apiDict[self._methodPath] =
> local.jsonCopy(self); // step 1 - deep-copy JSON-data first
> // init ajax
> self.ajax = function (swaggerJson, onError) { // step 2 - custom-copy/add 
> non-JSON-data in second-pass
> return local.apiAjax(self, swaggerJson, onError);
> };
> ```
> 
> [1] deep-copy swagger client-object with functions
> https://github.com/kaizhu256/node-swgg/blob/2018.9.8/lib.swgg.js#L2181 
> <https://github.com/kaizhu256/node-swgg/blob/2018.9.8/lib.swgg.js#L2181>
> 
> kai zhu
> kaizhu...@gmail.com <mailto:kaizhu...@gmail.com>
> 
> 
> 
>> On 23 Oct 2018, at 10:25 PM, Naveen Chawla > <mailto:naveen.c...@gmail.com>> wrote:
>> 
>> Correction, suppose const b = { a : b } . Circular references can be cloned 
>> trivially, as far as I can tell
>> 
>> On Tue, 23 Oct 2018 at 20:52 Naveen Chawla > <mailto:naveen.c...@gmail.com>> wrote:
>> Is there any real problem with circular reference cloning? I don't see any, 
>> Please let me know in the simplest case e.g. { a: a } (obviously contrived 
>> syntax here)
>> 
>> Otherwise, I agree completely about the 4 dots being the wrong syntax for 
>> this, precisely for the reason you gave
>> 
>> On Tue, 23 Oct 2018 at 18:18 Henrique Barcelos > <mailto:rick.hjpbarce...@gmail.com>> wrote:
>> IMO, this would be very problematic.
>> 
>> 1. 4 dots are visually almost identical to 3 dots. This could introduce 
>> severe bugs because of a simple hard to spot typo.
>> 
>> 2. Deep traversing will always have performance problems in some cases. 
>> Dealing with circular references can take this issue even further.
>> 
>> I believe such functionality should be used in very specific situations, 
>> where object shape is well-known, not very deep and definitely not circular. 
>> So, supporting this at the core of the language will probably be frowned 
>> upon by the community.
>> 
>> Em ter, 23 de out de 2018 08:57, Ahad Cove > <mailto:ahadc...@gmail.com>> escreveu:
>> Hello Scripters,
>> 
>> I really appreciate everything you all have done for the language and have 
>> no complaints over here.
>> I do have a suggestion though :)
>> 
>> At work we’ve almost got rid of lodash, except we still need it for DeepCopy 
>> vs rolling our own.
>> It’s the same with my side projects. I don’t use lodash because the main 
>> times that I need deep copy is when I’m either digging into the Redux store 
>> using React, or copying an observable in the Angular world.
>> 
>> I believe ES Script users would appreciate having a deep copy spread 
>> operator tremendously.
>> 
>> My proposal is to go off of the current spread operator we currently have in 
>> ES and make it 4 dots for a deep spread. This can be used on Objects or 
>> Arrays.
>> 
>> ‘’’js
>> const oldDeepObj = {
>>   InnerObj: {
>>func: () => return ‘wow’
>>}
>> }
>> 
>> const obj = {oldDeepObj}
>> obj.innerObj.func = () => return ‘nice’
>> 
>> oldDeepObj.innerObj.func()
>> > wow
>> ‘’’
>> 
>> Thank you!
>> Looking forward to hearing back from you all.
>> If there’s any other questions let me know
>> 
>> - Bilal Abdullah

Re: Deep spread operator (Bilal Abdullah)

[kai zhu]

hi Bilai, there’s no reliable way to deep-copy arbitrary js-objects. the most 
practical “general” solution is two-step:

1. deep-copy JSON-data first, e.g. ```var bb = JSON.parse(JSON.stringify(aa))```
2. custom-copy non-JSON-data in a second-pass, e.g. ```bb.innerObj.func = 
aa.innerObj.func```

like this real-world example [1]:

```javascript
local.jsonCopy = function (obj) {
/*
 * this function will [JSON] deep-copy obj
 */
return obj === undefined
? undefined
: JSON.parse(JSON.stringify(obj));
};
...
// update apiDict
self = local.apiDict[key.join('.')] = local.apiDict[self._methodPath] =
local.jsonCopy(self); // step 1 - deep-copy JSON-data first
// init ajax
self.ajax = function (swaggerJson, onError) { // step 2 - custom-copy/add 
non-JSON-data in second-pass
return local.apiAjax(self, swaggerJson, onError);
};
```

[1] deep-copy swagger client-object with functions
https://github.com/kaizhu256/node-swgg/blob/2018.9.8/lib.swgg.js#L2181

kai zhu
kaizhu...@gmail.com



> On 23 Oct 2018, at 10:25 PM, Naveen Chawla  wrote:
> 
> Correction, suppose const b = { a : b } . Circular references can be cloned 
> trivially, as far as I can tell
> 
> On Tue, 23 Oct 2018 at 20:52 Naveen Chawla  <mailto:naveen.c...@gmail.com>> wrote:
> Is there any real problem with circular reference cloning? I don't see any, 
> Please let me know in the simplest case e.g. { a: a } (obviously contrived 
> syntax here)
> 
> Otherwise, I agree completely about the 4 dots being the wrong syntax for 
> this, precisely for the reason you gave
> 
> On Tue, 23 Oct 2018 at 18:18 Henrique Barcelos  <mailto:rick.hjpbarce...@gmail.com>> wrote:
> IMO, this would be very problematic.
> 
> 1. 4 dots are visually almost identical to 3 dots. This could introduce 
> severe bugs because of a simple hard to spot typo.
> 
> 2. Deep traversing will always have performance problems in some cases. 
> Dealing with circular references can take this issue even further.
> 
> I believe such functionality should be used in very specific situations, 
> where object shape is well-known, not very deep and definitely not circular. 
> So, supporting this at the core of the language will probably be frowned upon 
> by the community.
> 
> Em ter, 23 de out de 2018 08:57, Ahad Cove  <mailto:ahadc...@gmail.com>> escreveu:
> Hello Scripters,
> 
> I really appreciate everything you all have done for the language and have no 
> complaints over here.
> I do have a suggestion though :)
> 
> At work we’ve almost got rid of lodash, except we still need it for DeepCopy 
> vs rolling our own.
> It’s the same with my side projects. I don’t use lodash because the main 
> times that I need deep copy is when I’m either digging into the Redux store 
> using React, or copying an observable in the Angular world.
> 
> I believe ES Script users would appreciate having a deep copy spread operator 
> tremendously.
> 
> My proposal is to go off of the current spread operator we currently have in 
> ES and make it 4 dots for a deep spread. This can be used on Objects or 
> Arrays.
> 
> ‘’’js
> const oldDeepObj = {
>   InnerObj: {
>func: () => return ‘wow’
>}
> }
> 
> const obj = {oldDeepObj}
> obj.innerObj.func = () => return ‘nice’
> 
> oldDeepObj.innerObj.func()
> > wow
> ‘’’
> 
> Thank you!
> Looking forward to hearing back from you all.
> If there’s any other questions let me know
> 
> - Bilal Abdullah
> ___
> es-discuss mailing list
> es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss 
> <https://mail.mozilla.org/listinfo/es-discuss>
> -- 
> Henrique
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss 
> <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: `maxDepth` on objects

[kai zhu]

hi Oliver, a practical solution to your nested-validation-problem is to use a 
recursive tree-walker that keeps track of depth.  here's a real-world example 
that limits the depth (to 3) for auto-generating swagger-data from 
nested-schemas using technique [1].

```javascript
local.dbFieldRandomCreate = function (options) {
/*
 * this function will create a random dbField from options.schemaP
 */
var depth, ii, max, min, schemaP, value;
depth = Number.isFinite(options.depth)
? options.depth
: 3;
...
// 5.4. Validation keywords for objects
default:
if (depth <= 0) {
break;
}
// recurse dbRowRandomCreate
value = local.dbRowRandomCreate({
depth: depth - 1,
modeNotRandom: options.modeNotRandom,
prefix: ['schema<' + JSON.stringify(schemaP) + '>'],
schema: schemaP
});
break;
```



hi TJ, a practical solution to circular-recursion is to have an Array/Set that 
records all unique objects the tree-walker has traversed, and which it checks 
against recursion.  here's a real-world example of swagger-validation guarding 
itself against circular schema-definitions using technique [2].

```javascript
local.swaggerValidateDataSchema = function (options) {
/*
 * this function will validate options.data against the swagger options.schema
 * http://json-schema.org/draft-04/json-schema-validation.html#rfc.section.5
 */
var $ref,
circularList,
...
circularList = [];
while (true) {
...
// dereference schema.$ref
$ref = schema && schema.$ref;
if (!$ref) {
break;
}
test = circularList.indexOf($ref) < 0;
local.throwSwaggerError(!test && {
data: data,
errorType: 'schemaDereferenceCircular',
prefix: options.prefix,
schema: schema
});
circularList.push($ref);
...
```



[1] maxDepth guard in auto-generating swagger-data from nested-schemas
https://github.com/kaizhu256/node-swgg/blob/2018.9.8/lib.swgg.js#L2377

[2] circular-schema guard in swagger-validation
https://github.com/kaizhu256/node-swgg/blob/2018.9.8/lib.swgg.js#L3940

kai zhu
kaizhu...@gmail.com



> On 21 Oct 2018, at 8:45 PM, Oliver Dunk  wrote:
> 
> I’d love to see some sort of `maxDepth` property on objects.
> 
> For `{}`, it would return `0`.
> In the case of `{keyOne: true}`, it would return `1`.
> For `{keyOne: {anotherKey: false}, keyTwo: false}`, it would return `2`.
> 
> My particular use case is validating a JSON payload sent by a user to prevent 
> abuse. I don’t want to force a particular structure or set of keys, but I do 
> want to make sure the level of nesting doesn’t get silly.
> 
> The code to implement this is fairly short, but looks a bit messy. It’d be 
> really nice to have a property instead.
> ___
> 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: JSON.parse should be simple and idiot-proof

[kai zhu]

i'm against all these proposals.  JSON.parse should remain zero-config and 
idiot-proof.  you will *always* need a second-pass in product-development to 
revive non-JSON datatypes anyways, like Date, and thats where reviving BigInt 
should take place as well.

again, i'm ok with working on web-projects where there are bugs in the 
second-pass (which is expected).  i'm not ok with web-projects, where i cannot 
reliably trust JSON.parse to do its job (and have to add it to checklist of 
things to inspect when figuring out where the bug is in end-to-end 
communications).

fyi, the twitter example is not compelling. it already has a string-form 
“id_str” which is more appropriate/easier-to-handle in javascript-land.  what 
benefit does a pseudorandom BigInt “id” (which has no need of arithmetic) have 
over plain-string “id_str” in javascript-land? none.

kai zhu
kaizhu...@gmail.com

> On 22 Oct 2018, at 2:59 AM, Peter Jaszkowiak  wrote:
> 
> What if `JSON.parse` took an options object as the second parameter?
> There's already been an instance of a JS API changing from booleans to an 
> options object: `addEventListener`.
> 
> I know it wasn't tc39, but it shows that it's possible. Another option is to 
> add a different method to the `JSON` object.
> 
> On Sun, Oct 21, 2018, 13:45 Richard Gibson  <mailto:richard.gib...@gmail.com>> wrote:
> Yes, understood. And setting aside the undesirable characteristics of boolean 
> trap <https://ariya.io/2011/08/hall-of-api-shame-boolean-trap> interfaces for 
> the moment (which will certainly be a source of regret if ECMAScript ever 
> gets a BigFloat), my point is that doing so would affect parsing of all 
> numbers, as opposed to only those numbers that really should be BigInts. For 
> example, let's look at a sample Twitter API entity 
> <https://developer.twitter.com/en/docs/tweets/data-dictionary/overview/tweet-object>:
> 
> {
>  "created_at":"Thu Apr 06 15:24:15 + 2017",
>  "id": 850006245121695744,
>  "id_str": "850006245121695744",
>  "text": "1/ Today we’re sharing our vision for the future of the Twitter API 
> platform!nhttps://t.co/XweGngmxlP <http://t.co/XweGngmxlP>",
>  "user": {
>   "id": 6253282,
>   "id_str": "6253282",
>   "name": "Twitter API",
>   "screen_name": "twitterapi",
>   "followers_count": 21,
>   "friends_count": 32
>  },  
>  "entities": {}
> }
> 
> It's nice that e.g. JSON.parse(…, null, true) would allow us to access the 
> ids as full-fidelity numbers (Twitter documents them as an int64), but much 
> less nice that the behavior would affect all numbers. For instance, let's say 
> this is one tweet in a list that we want to sort by the "follower ratio" of 
> their creators:
> 
> let creatorPopularity = tweet.user.followers_count / tweet.user.friends_count;
> // (without parse-as-BigInt) → 0.65625
> // (with parse-as-BigInt)→ 0n
> 
> We just silently lost floating-point arithmetic.
> 
> On Sun, Oct 21, 2018 at 1:00 PM Isiah Meadows  <mailto:isiahmead...@gmail.com>> wrote:
> This would be the correct understanding here, a 4th parameter read as a 
> boolean.
> 
> On Sun, Oct 21, 2018 at 12:27 Peter Jaszkowiak  <mailto:p.jasz...@gmail.com>> wrote:
> He was recommending a single parameter for "parse ints as bigints", not 
> changing the default behavior.
> 
> On Sun, Oct 21, 2018, 09:58 Richard Gibson  <mailto:richard.gib...@gmail.com>> wrote:
> First, note that reviver functions do manipulate the result after it's 
> parsed. Second, "parse ints as bigints" is too big a hammer—changing the 
> output for all numbers would break currently working code. And third, it's 
> not even fully sufficient for the "big numbers" purpose, which logically also 
> includes non-integers outside the IEEE 754 64-bit range ("BigFloat").
> 
> On Sun, Oct 21, 2018 at 10:50 AM Isiah Meadows  <mailto:isiahmead...@gmail.com>> wrote:
> Just because something exists doesn't mean it'll be  broadly used. Plus, 
> reviver functions are normally incredibly simple - you don't get enough 
> context (like key paths) to do anything crazy, and this proposal doesn't give 
> you enough context for that.
> 
> In practice, this changes literally nothing for most consumers, since the use 
> case is incredibly limited and usually requires server agreement as well. In 
> fact, that's where my skepticism lies: why add 3 new reviver parameters when 
> a single "parse ints as bigints" would solve basically the entire problem? 
> I've yet to see any other use case

JSON.parse should be simple and idiot-proof

[kai zhu]

wish to express skepticism for the stage-1 proposal "JSON.parse source text 
access" [1], from web-integration perspective.

a common javascript-painpoint is pinpointing bug-source of end-to-end 
client<->server communications.  thankfully, JSON.parse is rarely suspect in 
this process.  this proposal however, encourage developers to introduce 
bugs/doubts-of-reliability to JSON.parse, making integration bug-hunting more 
painful than it already is.

standard-operating-procedure for reviving JSON-data is a 2-step process:
1. JSON.parse with zero-config to rule-out bugs during this step
2. second-pass of plain-JSON to revive [product-specific] string-encoded 
non-JSON datatypes like BigInt/Date/RegExp, where bugs can be expected

you normally do not want to complicate bug-hunts by contaminating step-1 with 
bugs from step-2.

[1] stage-1 proposal - JSON.parse source text access
https://github.com/gibson042/ecma262-proposal-JSON-parse-with-source

kai zhu
kaizhu...@gmail.com



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

Re: Function Overloading or Pattern Matching of functions in Ecma

[kai zhu]

hi Bishwendu, javascript is first-and-foremost a tool designed for 
web-product-development, a growing field that has eclipsed low-level 
general-purpose programming (where jobs are harder and harder to find) in the 
IT industry.

you need to give compelling reasons (for such significant language-change) why 
i, a web-developer would benefit from from having overloaded-functions in my 
(mostly expendable-code) web-projects, as opposed to creating confusion and 
maintennance-headaches, when i typically have to rewrite code multiple-times 
during the web-integration process.

kai zhu
kaizhu...@gmail.com



> On 17 Oct 2018, at 12:23 PM, bishwendu kundu  wrote:
> 
> Hello All,
> 
> I have been a great fan of the evolution of JavaScript in the recent past. 
> The language is steadily closing the gap to ideal functional paradigm. One of 
> the things that I have liked the most about languages like 
> Erlang/Elixir/Haskell is their ability to define functions with same name and 
> different airty. The decision of invoking the correct function-argument 
> pattern is dependent on the invocation of the function. Implicit pattern 
> matching in aforementioned languages helps avoid costly cognitive loads 
> introduced by explicit if/else based pattern of logic flow branching.
> 
> The greatest power of the pattern matching which amazed me was, dropping the 
> whole of looping construct, altogether. Elixir/Erlang have no LOOPS. Stack 
> based recursive calls combined with JavaScript's closures suddenly strikes me 
> as a very powerful programming model that not only increases readability of 
> code but also promotes immutability of the data structures in use. The loops 
> would continue to exist but more modern codes can be written leveraging the 
> recursive model of JavaScript.
> 
> With de-structuring of arrays & objects already in place in JavaScript, 
> pattern-matching of functions can fit right in perfectly, thereby taking 
> JavaScript another step closer to ideal functional programming model.
> 
> Looking forward to your response.
> 
> Thanks & Regards,
> Bishwendu.
> ___
> 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: Array.prototype.remove(item)

[kai zhu]

> Not every object in JS is intended to travel between client and server, or to 
> be stored in JSON. And if/when the class want to share some information, it 
> can easily translate its data to and from a JSON-friendly format.

hi Claude, agree to disagree.  its impossible to predict/design what should and 
shouldn’t travel between client <-> server in javascript product-development.  

the best you can do as an “architect” is to accept that *anything* 
of-consequence in javascript will eventually need to "leak" itself to the 
"client <-> server <-> db JSON/urlstring dance", over the normal-flow of 
UX-features getting added to a product;  and that much of the tech-debt in 
these projects arise from needless class constructor/serialization hacks to 
make that dance happen, when it wasn’t expected (and could’ve been avoided by 
sticking with plain JSON data-structures).

even in esoteric, seemingly non-web-related cases like using duktape in c++:  
why would anyone want to have embedded js-capability in such scenario?  the 
only use-case that comes to mind is for manipulating JSON data-structures, and 
again, passing plain JSON-data between "c++ program" <-> “external web-system"

kai zhu
kaizhu...@gmail.com


> On 11 Oct 2018, at 5:14 AM, Claude Pache  wrote:
> 
> 
> 
>> Le 10 oct. 2018 à 23:17, kai zhu  a écrit :
>> 
>> hi Man, i don’t have strong opinion on Array.prototype.remove, but i have 
>> strong opinion against your use-case to subclass/extend Array.  from a 
>> product-development perspective, you're creating unnecessary 
>> integration-headaches by having the client <-> server system pass around 
>>  instances instead of plain JSON arrays.
> 
> Not every object in JS is intended to travel between client and server, or to 
> be stored in JSON. And if/when the class want to share some information, it 
> can easily translate its data to and from a JSON-friendly format. (Sorry, I’m 
> not motivated to read the rest of your e-mail.)
> 
> —Claude 
> 

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

Re: Array.prototype.remove(item)

[kai zhu]

hi Man, i don’t have strong opinion on Array.prototype.remove, but i have 
strong opinion against your use-case to subclass/extend Array.  from a 
product-development perspective, you're creating unnecessary 
integration-headaches by having the client <-> server system pass around 
 instances instead of plain JSON arrays.

i remain unconvinced of any real-world benefit to subclassing Array, that 
justifies the cost-added to already painful task of debugging end-to-end 
communication-issues between client <-> server.  your web-project will have a 
less-painful integration/qa process, if you stick with plain JSON arrays 
employing static-functions instead:

```javascript
/*jslint devel*/
(function () {
"use strict";
var myArray1;
function arrayRemoveItem(array, item) {
/**
 * This static-function will:
 * Remove the first occurrence of [item] from this array.
 * Return `true` if [item] was in this array, `false` otherwise.
 */
var i = array.indexOf(item);
if (i >= 0) {
array.splice(i, 1);
return true;
}
return false;
}
myArray1 = [1, 2, 3, 4]; // [1, 2, 3, 4]
console.log(arrayRemoveItem(myArray1, 2)); // true
console.log(myArray1); // [1, 3, 4]
}());
```

kai zhu
kaizhu...@gmail.com



> On 10 Oct 2018, at 3:01 PM, Man Hoang  wrote:
> 
> The problem with `Set` is that its `add` method returns `this` instead of 
> `boolean`. If `Set.prototype.add` returned `boolean`, I would have used `Set`.
>  
> That’s why in the `select` method of my sample code, I use a custom defined 
> method named `pushIfAbsent`. The actual type of `_values` is not `Array` but 
> a subclass of `Array`.
> ``` js
> export class MyArray extends Array {
> /**
>  * Adds [item] to the end of this array if it's not already in this array.
>  * 
>  * Returns `true` is [item] was added, `false` otherwise.
>  */
> pushIfAbsent(item: E): boolean {
> if (!this.includes(item)) {
> this.push(item);
> return true;
> }
> return false;
> }
>  
> /**
>  * Removes the first occurrence of [item] from this array.
>  * 
>  * Returns `true` if [item] was in this array, `false` otherwise.
>  */
> remove(item: E): boolean {
> const i = this.indexOf(item);
> if (i >= 0) {
> this.splice(i, 1);
> return true;
> }
> return false;
> }
> }
> ```
> ___
> es-discuss mailing list
> es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss 
> <https://mail.mozilla.org/listinfo/es-discuss>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "Redacted" global-namespace

[kai zhu]

+1 for unified global-object (currently stage-3)

can someone pm me what the redacted-name is?  i'm interested in polyfilling it 
for existing projects, e.g.:

```js
/*jslint browser*/
/*global global process*/
(function () {
/*
 * polyfill for
 * https://github.com/tc39/proposal-global
 * assuming redacted-name is "global2"
 */
"use strict";
var global2;
try {
global2 = process.versions.node && global;
} catch (ignore) {
}
global2 = global2 || window;
global2.global2 = global2;
}());
```

kai zhu
kaizhu...@gmail.com

> On 11 Aug 2018, at 1:29 AM, Jordan Harband  wrote:
> 
> The rationale is in the notes themselves.
> 
> Yes, we could do so in principle, but it's rarely useful to do so.
> 
> If the impact is insignificant, then we made nothing worse, just delayed some 
> information spreading for a few weeks/months. If the impact is significant, 
> then this has a positive effect.
> 
> I'm not seeing the downside.
> 
> On Fri, Aug 10, 2018 at 10:27 AM, kdex mailto:k...@kdex.de>> 
> wrote:
> I'd be interested to learn why it was decided to redact a possible new name 
> for `global` in the latest meeting notes[1].
> 
> Although I do understand that redacting the name minimizes its chance to gain 
> more usage, I doubt that the impact would be significant; if anything, I 
> think 
> people would have trouble to think of this form of standardization as "open".
> 
> By the same argument, we could in principle redact any new prototype/global 
> property, couldn't we? Is the intent not to cause a second "smooshgate"? 
> What's the point?
> 
> [1] https://github.com/rwaldron/tc39-notes/blob/master/es9/2018-07/
> july-24.md#new-name-for-global 
> <https://github.com/rwaldron/tc39-notes/blob/master/es9/2018-07/july-24.md#new-name-for-global>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss 
> <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: Removing a module from the cache

[kai zhu]

hi Isiah, i don’t feel your use-case is a valid one.  i've played with many 
crazy hot-module loading-techniques in my 7 years as a python-dev, and 
afterwards, first year as js-dev.  reflecting on all that time spent, what have 
i learned?  that for anything besides contrived toy-cases, i *never* trusted 
the modules would hot-load correctly, with properly resolved dependencies 
(especially inter-module class-inheritances, which was a factor why i'm hostile 
to inheritance-based design-patterns in dynamics-languages).  in practice i 
always ended up restarting the entire app/test-runner after file-updates due to 
paranoia, and there was alot of loader-related tech-debt i should have deleted 
years earlier, but didn’t due to sentimental value.

the *only* valid use-case for hot-loading modified-modules is during 
bootstrap-phase (with minimal integration-worries about module-dependency 
issues), so you can insert instrumentation-code for test-coverage like this 
real-world example [1].

[1] bootstrap to load modified-modules with instrumentation-code for 
test-coverage
https://github.com/kaizhu256/node-istanbul-lite/blob/2018.4.25/lib.istanbul.js#L2765
 
<https://github.com/kaizhu256/node-istanbul-lite/blob/2018.4.25/lib.istanbul.js#L2765>

kai zhu
kaizhu...@gmail.com



> On 21 Sep 2018, at 1:33 AM, Isiah Meadows  wrote:
> 
> I could seriously use the ability to remove, relative to a module, a
> loaded module from the cache.
> 
> - In my test runner, I don't want to have to append a random query
> just to reload all the test files in watch mode.
> - I was at one point running an experiment to try to use JS tagged
> templates as a template engine of sorts, but I can't really use ES
> modules because I need the ability to drop them from cache and
> re-import them manually.
> 
> I do not require any new syntax (it can just be a built-in exposed to
> hosts and maybe by hosts like Node), but I would like such a hook
> exposed.
> 
> This won't require much in the spec, but it will require three main
> spec changes:
> 
> - A new per-realm specifier blacklist (like maybe realm.[[Reload]]) added.
> - The third requirement in `HostResolveImportedModule` [1] altered to not
> require idempotence when the specifier is in the current realm's
> [[Reload]] list.
> - All callees to `HostResolveImportedModule` changed to also remove
> the specifier from the current realm's [[Reload]] list if the
> operation completed normally.
> 
> [1]: https://tc39.github.io/ecma262/#sec-hostresolveimportedmodule
> 
> -
> 
> Isiah Meadows
> cont...@isiahmeadows.com
> www.isiahmeadows.com
> ___
> 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: defer keyword

[kai zhu]

html_url: githubRepo.html_url,
created_at: githubRepo.created_at,
updated_at: githubRepo.updated_at,
size: githubRepo.size,
stargazers_count: githubRepo.stargazers_count
};
}),
null,
4   
));
// guarantee cleanup on successful-operation
onNext();
break;
// cleanup
default:
cleanup();
process.exit(Boolean(error));
        }
// guarantee cleanup on misc thrown-error
} catch (errorCaught) {
onNext(errorCaught);
}
};
modeNext = 0;
onNext();
}());
```

kai zhu
kaizhu...@gmail.com



> On 20 Sep 2018, at 11:48 PM, Isiah Meadows  wrote:
> 
> Could you chime in with this here as an alternative?
> https://github.com/tc39/proposal-using-statement
> 
> -
> 
> Isiah Meadows
> cont...@isiahmeadows.com
> www.isiahmeadows.com
> On Thu, Sep 20, 2018 at 7:36 AM kdex  wrote:
>> 
>> So, when is a function supposed to be invoked when `defer`red in a generator?
>> 
>> On Thursday, September 20, 2018 11:21:06 AM CEST Ayush Gupta wrote:
>>> Hi,
>>> 
>>> I would like to propose a `defer` keyword(or something else  as the keyword
>>> name) which would allow   us to "defer" a function which will be executed
>>> once the current function either returns or throws.
>>> 
>>> The idea for this is taken from the Go programming language.
>>> 
>>> It would allow us to perform cleanup activities in a function which has
>>> multiple branches in a single place.
>>> 
>>> For example, a sample server side code can look  like:
>>> 
>>> ```  js
>>> function doSomeDbWork() {
>>>const connection = databasepool.getConnection();
>>>defer function () { connection.release(); } // function would be called
>>> no matter when/if the function returns or throws
>>>//   do your work
>>> }
>>> ```
>>> 
>>> Regards
>>> Ayush Gupta___
>> 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: [nodejs] Re: javascript vision thing

[kai zhu]

this is not a troll-account, and I’m a live-person with realistic (albeit 
uncomfortable) views on limitations of javascript product-development in 
industry.

es6 seems to adopt java’s philosophy that with careful-planning, you can create 
semi-permanent, well-abstracted code during the design-phase that will last 
throughout the product-development cycle.  my experience with numerous 
web-projects, both successful and failed, indicates this approach as flawed.  
and i believe most people in industry who have been burned by failed 
web-projects in the past (due to over-encumbered/engineered initial-designs 
that couldn’t cope with realities of product integration/qa) are wary of hiring 
unproven java-turned-js devs who still hold these brittle design-philosophies.

there's no such thing as “permanent” javascript-code in product-development.  
everything eventually gets rewritten, when the inevitable business-critical ux 
feature-request comes in that you must accommodate, even though it breaks your 
current integration-workflow.  when this common scenario plays out in industry:

a) the [inexperienced] unqualified js-dev likely dithers, unwilling/unable to 
unwind the complicated initial-design they architected to accommodate the 
feature-request, while
b) the [experienced] qualified js-dev would have anticipated this, and simply 
rewrites their initial expendable-code with new expendable-code to accommodate 
the feature-request (with expectation it will be rewritten again-and-again in 
the future).

its difficult for employers to discern whether js-devs will exhibit trait a) or 
trait b) through technical-interview alone.  and es6 skews this with 
design-patterns biased towards trait a), further confusing employers seeking 
qualified js-devs.

kai zhu
kaizhu...@gmail.com



> On 23 Sep 2018, at 1:43 AM, Zlatko Đurić  wrote:
> 
> Hi all,
> 
> I don't know why I can't resist this troll. I've just spent half an hour 
> writing an elaborate answer on how the whole premise is wrong, knowing that 
> this is a known troll account. Well, I've deleted it all and will not fall 
> for his trolling again.
> 
>  (Btw I thought this list is moderated, how come his same-all troll ramblings 
> always pass the mods?)
> 
> Zlatko 
> 
> On Sat 22. Sep 2018 at 18:26, Michael J. Ryan  <mailto:track...@gmail.com>> wrote:
> Considering how many js devs fail to answer "what values evaluate to false in 
> JavaScript". It isn't the new features that are the problem.
> 
> There's a combination of problems.  People believing they're better 
> developers than they are.  People who look down on js and front end 
> development.  And those ahead to learn new things.
> 
> JS isn't really evolving any more than Java, C#, go, python and others as a 
> whole in the past 20 years.  And having to fight uphill to use newer features 
> is a pain.  I'm not on the younger side of this (I'm 42)... But I've managed 
> to keep up.
> 
> On Fri, Sep 21, 2018, 17:14 kai zhu  <mailto:kaizhu...@gmail.com>> wrote:
> a problem i've observed in industry is that many es6 language-features have 
> the unintended-consequence of incentivising incompetent javascript-developers 
> at the expense of competent-ones.  its generally difficult for many employers 
> (even those knowledgeable in general-purpose programming), to discern between:
> 
> a) a competent javascript employee/contractor who can get things done and 
> ship products (albeit with legitimate delays), and
> b) an incompetent-one who can easily hide themselves in non-productive es6 
> busywork, and continually pushback product-integration (again with 
> “legitimate” delays, until its too late).
> 
> its gotten bad enough that many industry-employers no longer trust 
> general-purpose-programming technical-interviews when recruiting js-devs, and 
> rely almost exclusively on either a) an applicant's reputation / 
> word-of-mouth for getting things done, or b) their ability to complete a 
> time-consuming tech-challenge, where they must demonstrate ability to ship a 
> mini-product.  both methods are not scalable to meet the demand in industry 
> for qualified js-devs in product-development.
> 
> the only solution i can think of to this industry-problem is to hold-back on 
> introducing new disruptive/unproven javascript design-patterns, and figuring 
> out how to educate the industry with tightened javascript style-guides and 
> existing design-patterns proven to work (more is less); generally, ways to 
> enhance the current, woefully inadequate “bullsh*t detector” of employers so 
> they can better identify and mentor/train/weed-out unqualified js-devs.
> 
> kai zhu
> kaizhu...@gmail.com <mailto:kaizhu...@gmail.com>
> 
> ___
> es-discuss mailing

Re: [nodejs] Re: javascript vision thing

[kai zhu]

yes, in order of severity:

1. es6 generators and modules are the top 2 notorious things that come to mind 
as being difficult to debug/integrate in product-development.

2. classes (and typescript, though not directly es6-related), tend to create 
lots of unnecessary structure that becomes a PITA when you need to rewrite 
everything, which occurs often in product-development.  there are lots of newly 
minted js-devs entering industry, who lack experience in understanding the 
risks of javascript over-engineering (and that nothing you write is permanent). 
 they write lots of semi-permanent, es6 infrastructure-code during the initial 
design-phase, which is a general no-no for many veterans, who understand most 
of that stuff is going to get tossed out the window and rewritten during 
integration-phase (and again everytime a ux feature-request comes in that 
breaks the existing integration-workflow).

3. let and const declarations.  most code you debug/write in javascript is 
ux-related integration-code dealing with async-io, which relies heavily on 
function-scoped closures to pass variables across process-ticks.  block-level 
scoping is an unnecessary design-pattern that leads to confusion over the 
former.

4. fat-arrow.  it has garden-path issues, making it difficult to write 
efficient javascript-parsers that can differentiate the following [valid] 
javascript-code:
```js
(aa = 1, bb = 2, cc = 3);
// vs
(aa = 1, bb = 2, cc = 3) => aa + bb;
```
this leads to fundamental performance-issues with 
tooling/minification/test-coverage-instrumenters.  jslint for 
efficiency-reasons, simply cheats and assumes both of the above are fat-arrows, 
and raises fat-arrow warnings for both (and halts further parsing) [1].

[1] jslint managing garden-path complexity of fat-arrow, with a single 
lookahead, that can turn out wrong, so it halts parsing.
https://github.com/douglascrockford/JSLint/blob/36adbc73ef0275df7d3fac9c3ef0844ac506136b/jslint.js#L2914
 
<https://github.com/douglascrockford/JSLint/blob/36adbc73ef0275df7d3fac9c3ef0844ac506136b/jslint.js#L2914>

kai zhu
kaizhu...@gmail.com



> On 22 Sep 2018, at 12:04 PM, Siegfried Bilstein  wrote:
> 
> Do you have examples of the patterns and es6 features you describe? 
> 
> Siggy
> 
> On Sat, Sep 22, 2018 at 01:02 kai zhu  <mailto:kaizhu...@gmail.com>> wrote:
> a problem i've observed in industry is that many es6 language-features have 
> the unintended-consequence of incentivising incompetent javascript-developers 
> at the expense of competent-ones.  its generally difficult for many employers 
> (even those knowledgeable in general-purpose programming), to discern between:
> 
> a) a competent javascript employee/contractor who can get things done and 
> ship products (albeit with legitimate delays), and
> b) an incompetent-one who can easily hide themselves in non-productive es6 
> busywork, and continually pushback product-integration (again with 
> “legitimate” delays, until its too late).
> 
> its gotten bad enough that many industry-employers no longer trust 
> general-purpose-programming technical-interviews when recruiting js-devs, and 
> rely almost exclusively on either a) an applicant's reputation / 
> word-of-mouth for getting things done, or b) their ability to complete a 
> time-consuming tech-challenge, where they must demonstrate ability to ship a 
> mini-product.  both methods are not scalable to meet the demand in industry 
> for qualified js-devs in product-development.
> 
> the only solution i can think of to this industry-problem is to hold-back on 
> introducing new disruptive/unproven javascript design-patterns, and figuring 
> out how to educate the industry with tightened javascript style-guides and 
> existing design-patterns proven to work (more is less); generally, ways to 
> enhance the current, woefully inadequate “bullsh*t detector” of employers so 
> they can better identify and mentor/train/weed-out unqualified js-devs.
> 
> kai zhu
> kaizhu...@gmail.com <mailto:kaizhu...@gmail.com>
> 
> 
> -- 
> Job board: http://jobs.nodejs.org/ <http://jobs.nodejs.org/>
> New group rules: 
> https://gist.github.com/othiym23/9886289#file-moderation-policy-md 
> <https://gist.github.com/othiym23/9886289#file-moderation-policy-md>
> Old group rules: 
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines 
> <https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines>
> --- 
> You received this message because you are subscribed to the Google Groups 
> "nodejs" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to nodejs+unsubscr...@googlegroups.com 
> <mailto:nodejs+unsubscr...@googlegroups.com>.
> To post to this group, send email to nod...@googlegroups.com 
> <mailt

Re: javascript vision thing

[kai zhu]

a problem i've observed in industry is that many es6 language-features have the 
unintended-consequence of incentivising incompetent javascript-developers at 
the expense of competent-ones.  its generally difficult for many employers 
(even those knowledgeable in general-purpose programming), to discern between:

a) a competent javascript employee/contractor who can get things done and ship 
products (albeit with legitimate delays), and
b) an incompetent-one who can easily hide themselves in non-productive es6 
busywork, and continually pushback product-integration (again with “legitimate” 
delays, until its too late).

its gotten bad enough that many industry-employers no longer trust 
general-purpose-programming technical-interviews when recruiting js-devs, and 
rely almost exclusively on either a) an applicant's reputation / word-of-mouth 
for getting things done, or b) their ability to complete a time-consuming 
tech-challenge, where they must demonstrate ability to ship a mini-product.  
both methods are not scalable to meet the demand in industry for qualified 
js-devs in product-development.

the only solution i can think of to this industry-problem is to hold-back on 
introducing new disruptive/unproven javascript design-patterns, and figuring 
out how to educate the industry with tightened javascript style-guides and 
existing design-patterns proven to work (more is less); generally, ways to 
enhance the current, woefully inadequate “bullsh*t detector” of employers so 
they can better identify and mentor/train/weed-out unqualified js-devs.

kai zhu
kaizhu...@gmail.com

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

tc39 agenda item - Hashbang for stage 2

[kai zhu]

fyi, jslint recently added linting support for hashbang/shebang [1].  so it 
seems the big 3 linters all support this agenda item now [2].

[1] jslint commit - ignore shebang in beginning of command-line scripts
https://github.com/douglascrockford/JSLint/commit/04f838b3986c8e0f02e56438aade342552aac93f#diff-01d3d81a6eb6d82af3c377b55dc4fa28R586
 
<https://github.com/douglascrockford/JSLint/commit/04f838b3986c8e0f02e56438aade342552aac93f#diff-01d3d81a6eb6d82af3c377b55dc4fa28R586>

[2] tc39 agenda items
https://github.com/tc39/agendas/blob/master/2018/09.md#agenda-items 
<https://github.com/tc39/agendas/blob/master/2018/09.md#agenda-items>
kai zhu
kaizhu...@gmail.com



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

Re: better coordination between nodejs and tc39 (javascript-standards-committee)

[kai zhu]

thx for the resource

On Sep 8, 2018 08:49, "Gus Caplan"  wrote:

Hello Kai,

There are several members of TC39 who are also active with Node.js
development, and proposals do move through TC39 that come from needs in
Node.js, like the recent https://github.com/guybedford/
proposal-dynamic-modules.

Moving forward, Node.js has started an initiative to work more with open
standard groups, including TC39.

You can follow along here: https://github.com/nodejs/open-standards

-Gus


 On Fri, 07 Sep 2018 20:38:48 -0500 *kai zhu >* wrote 

are any members of nodejs tsc [1] also members of tc39 [2]?  in recent
tc39-notes [3] there are references to nodejs, but seemingly always in 3rd
person.  since all major browser-vendors have representatives at tc39’s
twice-a-month meetings (either in-person or video-conf), i think it would
make sense for nodejs to have a representative as well (if it doesn’t
already).

[1] nodejs technical steering committee
https://github.com/nodejs/TSC

[2] ecma tc39 (javascript-standards) committee
https://www.ecma-international.org/memento/tc39-m.htm

[3] tc39-discussion on creating a javascript standard-library aligned with
nodejs
https://github.com/rwaldron/tc39-notes/commit/51f2ae851b75e167f426814ecc5942
401537e3c2#diff-b44ce5f0c2c0281137b7c01453115401R555

kai zhu
kaizhu...@gmail.com



___
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: better coordination between nodejs and tc39 (javascript-standards-committee)

[kai zhu]

thx for the resource

On Sep 8, 2018 08:49, "Gus Caplan"  wrote:

> Hello Kai,
>
> There are several members of TC39 who are also active with Node.js
> development, and proposals do move through TC39 that come from needs in
> Node.js, like the recent https://github.com/guybedford/
> proposal-dynamic-modules.
>
> Moving forward, Node.js has started an initiative to work more with open
> standard groups, including TC39.
>
> You can follow along here: https://github.com/nodejs/open-standards
>
> -Gus
>
>
>  On Fri, 07 Sep 2018 20:38:48 -0500 *kai zhu  >* wrote 
>
> are any members of nodejs tsc [1] also members of tc39 [2]?  in recent
> tc39-notes [3] there are references to nodejs, but seemingly always in 3rd
> person.  since all major browser-vendors have representatives at tc39’s
> twice-a-month meetings (either in-person or video-conf), i think it would
> make sense for nodejs to have a representative as well (if it doesn’t
> already).
>
> [1] nodejs technical steering committee
> https://github.com/nodejs/TSC
>
> [2] ecma tc39 (javascript-standards) committee
> https://www.ecma-international.org/memento/tc39-m.htm
>
> [3] tc39-discussion on creating a javascript standard-library aligned with
> nodejs
> https://github.com/rwaldron/tc39-notes/commit/
> 51f2ae851b75e167f426814ecc5942401537e3c2#diff-
> b44ce5f0c2c0281137b7c01453115401R555
>
> kai zhu
> kaizhu...@gmail.com
>
>
>
> ___
> 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: stable sort proposal

[kai zhu]

+1

it would avoid stable-sort workarounds like this [1], [2] for 
javascript-database implementations.

[1] testable, deterministic, stable-sort workaround for querying rows from 
db-lite
https://github.com/kaizhu256/node-db-lite/blob/2018.4.23/lib.db.js#L1010 
<https://github.com/kaizhu256/node-db-lite/blob/2018.4.23/lib.db.js#L1010>

[2] accompanying integration-tests to ensure reproducible, sorted db-queries
https://github.com/kaizhu256/node-db-lite/blob/2018.4.23/test.js#L64 
<https://github.com/kaizhu256/node-db-lite/blob/2018.4.23/test.js#L64>

kai zhu
kaizhu...@gmail.com



> On 12 Sep 2018, at 5:09 AM, 森建  wrote:
> 
> `Array#sort` is stable in Chrome 70.
> https://twitter.com/mathias/status/1036626116654637057
> 
> All modern browsers (and IE 11) have stable sort with `Array#sort`. Would you 
> like to mention `Array#sort` must be a stable sort on specification 
> (>=ES2019)?
> ___
> 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

better coordination between nodejs and tc39 (javascript-standards-committee)

[kai zhu]

are any members of nodejs tsc [1] also members of tc39 [2]?  in recent 
tc39-notes [3] there are references to nodejs, but seemingly always in 3rd 
person.  since all major browser-vendors have representatives at tc39’s 
twice-a-month meetings (either in-person or video-conf), i think it would make 
sense for nodejs to have a representative as well (if it doesn’t already). 

[1] nodejs technical steering committee
https://github.com/nodejs/TSC <https://github.com/nodejs/TSC>

[2] ecma tc39 (javascript-standards) committee
https://www.ecma-international.org/memento/tc39-m.htm 
<https://www.ecma-international.org/memento/tc39-m.htm>

[3] tc39-discussion on creating a javascript standard-library aligned with 
nodejs
https://github.com/rwaldron/tc39-notes/commit/51f2ae851b75e167f426814ecc5942401537e3c2#diff-b44ce5f0c2c0281137b7c01453115401R555
 
<https://github.com/rwaldron/tc39-notes/commit/51f2ae851b75e167f426814ecc5942401537e3c2#diff-b44ce5f0c2c0281137b7c01453115401R555>
kai zhu
kaizhu...@gmail.com



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

Re: let-in if do-expr is problematic? (was: Re: proposal: let in if parentheses)

[kai zhu]

agree that “stupid” was a too-strong word, but the scope of es6-modules 
honestly was a mistake when we reflect on it with 20/20 hindsight.  imagine an 
alternate-timeline where tc39 had instead gone with a 
smaller-scope/conservative/gatekeeper approach of expanding on commonjs-modules 
instead.  most web-developers would probably agree such a scenario would've 
been more conducive to web-development:

- it would’ve mitigated significantly, the tooling-hell associated with es6 
web-projects that makes them riskier than es5 web-projects.

- we wouldn’t have the issue of every es6 web-project being permanently stuck 
with context-switching between commonjs-modules and es6-modules, because its 
impossible to reinvent all relevant commonjs-modules as es6-modules

- we wouldn’t have awkward conversations when teaching beginners on why the 
language has [soon-to-be] 3 different module-loading systems: 1) 
commonjs-require, 2) static-import, and 3) dynamic-import (which is 
essentially/cross-cutting commonjs-require *except its not* because we don’t 
want to admit that [asynchronous?] static-import turns out to be too confusing 
and difficult-to-use for frontend-developers).

this is a cautionary-tale of what happens in design-by-comittee, where not 
enough committee-members clearly thought-through the big-picture impact to 
industry of what they were doing.

kai zhu
kaizhu...@gmail.com



> On 23 Aug 2018, at 11:07 PM, Jordan Harband  wrote:
> 
> It's off topic to the thread, so either way it's not appropriate to bring it 
> up here.
> 
> It's not objectively a mistake, and calling it "stupid" is absolutely toxic. 
> Be nice, or don't participate. I'll refer you to 
> https://github.com/tc39/code-of-conduct 
> <https://github.com/tc39/code-of-conduct> which governs this list as well.
> 
> On Thu, Aug 23, 2018 at 2:14 AM, kai zhu  <mailto:kaizhu...@gmail.com>> wrote:
>> Dependency resolution logic is platform-specific
> 
> 
> @jordan, platform-specific logic is not a real problem?  the behavior of 
> import-statement between babel (sync), native-browser (async), native-nodejs 
> (sync???) are all subtly different.  and yes, it's effectively a 
> with-statement.
> 
> its not toxicity.  its reminding tc39 of their mistakes, so they don’t repeat 
> something again as stupid and harmful to industry/web-development in the 
> future.
> 
> kai zhu
> kaizhu...@gmail.com <mailto:kaizhu...@gmail.com>
> 
> 
> 
>> On 23 Aug 2018, at 1:22 PM, Jordan Harband > <mailto:ljh...@gmail.com>> wrote:
>> 
>> Kai, that makes no sense whatsoever, and isn't contributing productively to 
>> this thread. Dependency resolution logic is platform-specific - in browsers, 
>> it's "URLs", which I assume you understand, and in node using babel, it's 
>> "the same as require", which I'd assume any node user would understand. 
>> There's no relationship to "with" statements and no actual difficulty 
>> "debugging" them that I'm aware of after using them for years.
>> 
>> Please stay on topic, and keep to yourself comments that are nothing more 
>> than random toxicity about the JS language.
>> 
>> On Wed, Aug 22, 2018 at 5:12 AM, kai zhu > <mailto:kaizhu...@gmail.com>> wrote:
>> es6 import-statements are effectively with-statements …
>> 
>> actually, they're *async* with-statements, with no callback-handling and 
>> non-obvious dependency-resolution logic, for those of us trying to debug 
>> them when things go wrong.
>> 
>> 
>> On Aug 22, 2018 15:58, "Claude Pache" > <mailto:claude.pa...@gmail.com>> wrote:
>> 
>> 
>> > Le 21 août 2018 à 21:20, Herbert Vojčík > > <mailto:he...@mailbox.sk>> a écrit :
>> > 
>> > Hi!
>> > 
>> > It would be nice to know if do expressions have some a chance, otherwise 
>> > some other syntax for let-in would be really helpful, especially now that 
>> > we have arrow functions.
>> > 
>> > I would propose to use different variant of let (maybe also const):
>> > 
>> > OP 1:
>> > 
>> >  let in a = b(), if (a) a.c();
>> > 
>> > OP 2:
>> > 
>> >  let in a = b(), if (a) c(a);
>> > 
>> > Instead of
>> >  const big = raw => {
>> >let cooked = cook(raw);
>> >return consumer => {
>> >  // do things with consumer and cooked
>> >};
>> >  };
>> > 
>> >  const big = raw =>
>> >let in cooked = cook(raw), consume => {
>> >  // do things with consumer and cooked
>> > 

Re: let-in if do-expr is problematic? (was: Re: proposal: let in if parentheses)

[kai zhu]

> Dependency resolution logic is platform-specific


@jordan, platform-specific logic is not a real problem?  the behavior of 
import-statement between babel (sync), native-browser (async), native-nodejs 
(sync???) are all subtly different.  and yes, it's effectively a with-statement.

its not toxicity.  its reminding tc39 of their mistakes, so they don’t repeat 
something again as stupid and harmful to industry/web-development in the future.

kai zhu
kaizhu...@gmail.com



> On 23 Aug 2018, at 1:22 PM, Jordan Harband  wrote:
> 
> Kai, that makes no sense whatsoever, and isn't contributing productively to 
> this thread. Dependency resolution logic is platform-specific - in browsers, 
> it's "URLs", which I assume you understand, and in node using babel, it's 
> "the same as require", which I'd assume any node user would understand. 
> There's no relationship to "with" statements and no actual difficulty 
> "debugging" them that I'm aware of after using them for years.
> 
> Please stay on topic, and keep to yourself comments that are nothing more 
> than random toxicity about the JS language.
> 
> On Wed, Aug 22, 2018 at 5:12 AM, kai zhu  <mailto:kaizhu...@gmail.com>> wrote:
> es6 import-statements are effectively with-statements …
> 
> actually, they're *async* with-statements, with no callback-handling and 
> non-obvious dependency-resolution logic, for those of us trying to debug them 
> when things go wrong.
> 
> 
> On Aug 22, 2018 15:58, "Claude Pache"  <mailto:claude.pa...@gmail.com>> wrote:
> 
> 
> > Le 21 août 2018 à 21:20, Herbert Vojčík  > <mailto:he...@mailbox.sk>> a écrit :
> > 
> > Hi!
> > 
> > It would be nice to know if do expressions have some a chance, otherwise 
> > some other syntax for let-in would be really helpful, especially now that 
> > we have arrow functions.
> > 
> > I would propose to use different variant of let (maybe also const):
> > 
> > OP 1:
> > 
> >  let in a = b(), if (a) a.c();
> > 
> > OP 2:
> > 
> >  let in a = b(), if (a) c(a);
> > 
> > Instead of
> >  const big = raw => {
> >let cooked = cook(raw);
> >return consumer => {
> >  // do things with consumer and cooked
> >};
> >  };
> > 
> >  const big = raw =>
> >let in cooked = cook(raw), consume => {
> >  // do things with consumer and cooked
> >};
> > 
> > In short,
> > 
> >  let in binding = expr, stmt|expr
> > 
> > It may work for `const in` as well.
> > 
> > Herby
> > 
> > P.S.: Alternative syntax is "let a=3, b=4, ..., in foo(a,b,c,d)" but this 
> > can only tell late if it is plain let-up-to-end-of-scope or 
> > local-scope-let, so not sure if that may be a problem; OTOH you can chain 
> > more of them and resembles classical let-in better.
> 
> Please, don’t take it too seriously: but have you thought about resuscitating 
> the (in)famous `with` statement?
> 
> ```js
> const big = raw => 
> do with ({cooked: cook(raw)})
> consumer => {
> // do things with consumer and cooked
> };;
> ```
> 
> And no the two ”;”s are not a typo: I need to end both the `with` statement 
> and the `const` declaration.
> 
> But more seriously... those sorts of “clever” syntaxes (`let-in` or `do-with` 
> or whatever), apart from complicating the language, are in danger of raising 
> as much issues than they’re resolving; the double-semicolon oddity is one of 
> them.
> 
> —Claude
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss 
> <https://mail.mozilla.org/listinfo/es-discuss>
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss 
> <https://mail.mozilla.org/listinfo/es-discuss>
> 
> 

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

Re: let-in if do-expr is problematic? (was: Re: proposal: let in if parentheses)

[kai zhu]

es6 import-statements are effectively with-statements …

actually, they're *async* with-statements, with no callback-handling and
non-obvious dependency-resolution logic, for those of us trying to debug
them when things go wrong.

On Aug 22, 2018 15:58, "Claude Pache"  wrote:

>
>
> > Le 21 août 2018 à 21:20, Herbert Vojčík  a écrit :
> >
> > Hi!
> >
> > It would be nice to know if do expressions have some a chance, otherwise
> some other syntax for let-in would be really helpful, especially now that
> we have arrow functions.
> >
> > I would propose to use different variant of let (maybe also const):
> >
> > OP 1:
> >
> >  let in a = b(), if (a) a.c();
> >
> > OP 2:
> >
> >  let in a = b(), if (a) c(a);
> >
> > Instead of
> >  const big = raw => {
> >let cooked = cook(raw);
> >return consumer => {
> >  // do things with consumer and cooked
> >};
> >  };
> >
> >  const big = raw =>
> >let in cooked = cook(raw), consume => {
> >  // do things with consumer and cooked
> >};
> >
> > In short,
> >
> >  let in binding = expr, stmt|expr
> >
> > It may work for `const in` as well.
> >
> > Herby
> >
> > P.S.: Alternative syntax is "let a=3, b=4, ..., in foo(a,b,c,d)" but
> this can only tell late if it is plain let-up-to-end-of-scope or
> local-scope-let, so not sure if that may be a problem; OTOH you can chain
> more of them and resembles classical let-in better.
>
> Please, don’t take it too seriously: but have you thought about
> resuscitating the (in)famous `with` statement?
>
> ```js
> const big = raw =>
> do with ({cooked: cook(raw)})
> consumer => {
> // do things with consumer and cooked
> };;
> ```
>
> And no the two ”;”s are not a typo: I need to end both the `with`
> statement and the `const` declaration.
>
> But more seriously... those sorts of “clever” syntaxes (`let-in` or
> `do-with` or whatever), apart from complicating the language, are in danger
> of raising as much issues than they’re resolving; the double-semicolon
> oddity is one of them.
>
> —Claude
>
> ___
> 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: JSON support for BigInt in ES6. Was: javascript vision thing

[kai zhu]

@isiah, actionable items before stage-4 are currently being debated @
https://github.com/tc39/proposal-bigint/issues/162

On Aug 1, 2018 14:00, "Isiah Meadows"  wrote:

> > Is 1 a byte, int, double, BigInt or BigNumber?  You tell me!  This
> obviously
> > has major consequences for parsers.  However, as long as you stay with
> the
> > original JS Number scope everything works just fine.
>
> BTW, most strongly typed languages parse numbers one of two ways:
>
> - If it's just digits, it's parsed as an integer (typically an `int` or
> `long`)
> - If it has floating point stuff, it's parsed as a float (typically a
> `double`)
>
> > Other people (including myself) are more pragmatic and pretty much
> dismiss
> > JSON Number as a suitable notation for numbers outside of the original JS
> > scope.  This view is also aligned with most IETF and W3C standards to
> date
> > defining JSON structures.
>
> In general, JSON is great for prototyping protocols and easy
> serialization when performance *isn't* a major concern, but that's
> about it. (It's better than XML and more performant than it, but it's
> still needlessly complex to parse/serialize.)
>
> -
>
> Isiah Meadows
> cont...@isiahmeadows.com
> www.isiahmeadows.com
>
>
> On Wed, Aug 1, 2018 at 1:51 AM, Anders Rundgren
>  wrote:
> > Richard et al,
> >
> > If we call the situation "limbo" or not isn't that important, I just
> happen
> > to have a preference for strong or funny expressions.
> >
> > The root of the problem (not only for JavaScript) is that JSON is *the
> only
> > general purpose data interchange format in existence* that uses a single
> > notion to signal "here comes a number".
> >
> > Is 1 a byte, int, double, BigInt or BigNumber?  You tell me!  This
> obviously
> > has major consequences for parsers.  However, as long as you stay with
> the
> > original JS Number scope everything works just fine.
> >
> > One camp suggests that the right solution is to use some kind of
> BigNumber
> > as the underlying Number type which surely is one way dealing with *data
> > type overloading*.
> >
> > Other people (including myself) are more pragmatic and pretty much
> dismiss
> > JSON Number as a suitable notation for numbers outside of the original JS
> > scope.  This view is also aligned with most IETF and W3C standards to
> date
> > defining JSON structures.
> >
> > Now to the challenge: Create a scheme that makes everybody happy!  Well,
> to
> > be more realistic; create something that maybe nobody really likes, by
> > supporting BOTH of the opposing views.
> >
> > Feel free slashing my minuscule change proposal:
> > https://github.com/tc39/proposal-bigint/issues/162#
> issuecomment-408679884
> >
> > Cheers,
> > Anders
> > On 2018-08-01 05:37, Richard Gibson wrote:
> >>
> >> JSON is defined by ECMA-404 and RFC 8259, not by ECMA-262. An ECMAScript
> >> JSON.parse implementation simply cannot accept e.g. 0n and still uphold
> the
> >> conformance guarantees  >:
> >>
> >> Conforming implementations of *JSON.parse* and *JSON.stringify* must
> >> support the exact interchange format described in the ECMA-404
> specification
> >> without any deletions or extensions to the format.
> >>
> >>
> >> Both BigInt and Symbol lack native support in JSON, and although adding
> in
> >> custom serialization is relatively easy, custom parsing is not because
> >> JSON.parse doesn't expose the text used to produce a value. But in my
> >> opinion, it would be a mistake to characterize that explicit lack of
> support
> >> as "limbo".
> >>
> >> On Sat, Jul 28, 2018 at 1:02 AM Anders Rundgren
> >> mailto:anders.rundgren@gmail.com>>
> >> wrote:
> >>
> >> On 2018-07-28 00:34, Richard Gibson wrote:
> >>  > As stated even more strongly in ECMA-404:
> >>  >
> >>  > Because it is so simple, it is not expected that the JSON
> >> grammar will ever change. This gives JSON, as a foundational notation,
> >> tremendous stability.
> >>  >
> >>
> >> Richard, that's great but it doesn't completely respond to my
> "limbo"
> >> claim:
> >>
> >> https://mail.mozilla.org/pipermail/es-discuss/2018-July/051388.html
> >>
> >> Take your pick! Whatever you come up with, I'm sure there will be
> some
> >> rotten tomatoes flying around :-)
> >>
> >> Cheers,
> >> Anders
> >>
> >
> > ___
> > 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: JSON support for BigInt in Chrome/V8

[kai zhu]

i support @anders’ *conservative* scheme and opened up a github-issue to try 
and get it included before stage-4 [1].  this might be one of the 
last-opportunities to change the behavior before its set-in-stone.

there was a previous github-issue on bigint JSON-support [2] (that led to the 
current behavior no one is happy about), but it never discussed the 
*conservative* scheme, hence the revisit.

to summarize, the *conservative* scheme basically copies the same JSON-behavior 
as Date.  users are already familiar with serializing Date, so there shouldn’t 
be any surprises (or at least less-surprises than throwing an error).  this is 
the simplest, actionable, and least-offensive-to-all-parties solution i can 
think of (unless someone has a less-offensive-to-all idea).  its also 
applicable in solving the same-issue for future primitives like BigDecimal.

```js
var aa;

// we copy JSON-behavior of Date
aa = 12345678901234567890n // 
aa = JSON.stringify(aa) // '"12345678901234567890"' (escaped string)
aa = JSON.parse(aa) // '12345678901234567890' (un-escaped string)
aa = BigInt(aa) //  (no precision-loss)

aa = new Date() // 
aa = JSON.stringify(aa) // '"2018-07-28T09:41:47.519Z"'' (escaped string)
aa = JSON.parse(aa) // '2018-07-28T09:41:47.519Z' (un-escaped string)
aa = new Date(aa) // 
```

[1] github-issue - revisit: Support JSON serialisation of BigInt values
https://github.com/tc39/proposal-bigint/issues/162 
<https://github.com/tc39/proposal-bigint/issues/162>

[2] github-issue - [closed] Support JSON serialisation of BigInt values
https://github.com/tc39/proposal-bigint/issues/24 
<https://github.com/tc39/proposal-bigint/issues/24>

kai zhu
kaizhu...@gmail.com



> On 29 Jul 2018, at 12:17 PM, Anders Rundgren  
> wrote:
> 
> As I have tried (apparently in vain) to describe, the other languages already 
> have solutions for BigInt (and much more), which the respectively authors 
> consider both sufficient and good.
> 
> ES6 is pretty late in the game and therefore rather have to adapt itself to 
> the other players.
> 
> These are the options:
> https://esdiscuss.org/topic/json-support-for-bigint-in-chrome-v8#content-30
> 
> - "Conservative" works right out of the box (although in a somewhat inelegant 
> way).  It is backward compatible with many existing ES and non-ES JSON based 
> applications.
> 
> - "RFC8259" support would require changes to the ES6 JSON object.  For 
> parsing (`JSON.parse2()`), a `JSONNumber` object as proposed by Michael 
> Theriot seems like a candidate.
> 
> I have limited faith in extending the (for general purpose information 
> interchange) already pretty deficient JSON type scheme; state-of-the-art 
> applications check indata anyway making explicit type information redundant.
> 
> Anders

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

Re: javascript vision thing

[kai zhu]

> Classes are widely used on the web. See any modern web framework.

indeed, and i conjecture in doing so, developers have caused more harm than
good for their employers in getting their web-projects shipped, when
JSON-serialization web-integration problems arise.

On Jul 25, 2018 17:44, "Michael Theriot" 
wrote:
>
> Classes are widely used on the web. See any modern web framework.
>
>
> On Wednesday, July 25, 2018, kai zhu  wrote:
>>
>> @tj, would you or i care about nodejs/javascript if the language did not
exist in browsers?  in fact would anyone on tc39 give a damn about
javascript (aside from its creator) in that scenario?  as i've said before
[ad nauseam], the only drive most of us [non-frontend-developers] have in
javascript is making our backend-programs accessible to the masses via
browsers/webviews.  javascript’s dominance/relevance in industry is as a
*web-integration* language.  and its aided by its special-ability to
directly serialize JSON data-structures (an underrated, and very useful
web-integration feature), while most of its competitors have to rely on
clumsy, hard-to-serialize classes.
>>
>> there is no foreseeable future where javascript will be a better tool
than java/c++/python/etc. for non web-related projects.  there is
no foreseeable future where employers would hire nodejs-developers to work
on non web-related projects.  so why does tc39 insist on pushing
distracting language-features (clumsy java-like classes,
non-integration-friendly meta-programming, static module-loading, etc.) for
an unrealistic future-scenario that’s not going to happen?
>>
>> kai zhu
>> kaizhu...@gmail.com
>>
>>> On 24 Jul 2018, at 5:56 PM, T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:
>>>
>>> On Tue, Jul 24, 2018 at 11:27 AM, kai zhu  wrote:
>>>>
>>>> tldr - tc39 should focus more on JSON-friendly
javascript-language-features
>>>> instead of wasting-time on hard-to-serialize classes/meta-programming.
>>>
>>>
>>> This is a false dichotomy (the fallacy of the either/or choice). I'd
>>> agree we're approaching, or at, the need for the next thing after
>>> JSON, and that some focus on that would be a good thing. That doesn't
>>> mean stopping work on other good things. Perhaps you could take the
>>> lead on addressing the issues you run into. I'm sure constructive
>>> input would be welcomed.
>>>
>>>> my problem with tc39, is that they “claim” javascript is a
general-purpose
>>>> language (and try to design it as such), when industry-wise, its
really not.
>>>
>>>
>>> Yes, it is. Just because you don't see it that way doesn't mean others
>>> don't. And others have been telling you they see it differently
>>> repeatedly over a long period of time on this list.
>>>
>>>> if tc39 is sincerely
>>>> interested in keeping javascript a dominant/relevant language in
industry,
>>>> they should focus on *practical* (vs *academic*) features
>>>
>>>
>>> `class` notation is practical (simplifying a common pattern and making
>>> it less error-prone). (I know you don't use that pattern. That's fine.
>>> But lots of people do, so it's practical for them whether you like the
>>> pattern or not.) Promises are practical (simplifying and standardizing
>>> callbacks, making them composable; again making them less
>>> error-prone). `async`/`await` is HUGELY practical, massively
>>> simplifying writing asynchronous code. Arrow functions, rest and
>>> spread, default parameter values -- all practical. (NOT trying to put
>>> words in your mouth, but if you were going to reply "Yes, but those
>>> problems could already be solved in others ways.", then: Sure, and we
>>> could all write assembly code, too. But it's *useful* to address these
>>> in the language.)
>>>
>>> All of them are useful beyond the web. All are also useful in web
programming.
>>>
>>> I have no problem with skepticism of specific proposals. What I would
>>> find useful, though, would be a focus on the proposal's merits, rather
>>> than constant re-raising of this claim that JavaScript is a web-only
>>> language. You've made that claim, ad nauseum. My view is that it's
>>> been rejected by the list membership and by TC39, but whether that's
>>> true or I'm mistaken, please stop spamming the list with it. We all
>>> know how you feel about it.
>>>
>>> But again: I'm sure constructive, research-based input on how to deal
>>> with JSON issues related to (for instance) BigInt would be welcome in
>>> that BigInt thread and, ideally, eventually a proposal. There's no
>>> need for some big conceptual argument over the course of the language
>>> -- that *is* a waste of time.
>>>
>>> -- T.J. Crowder
>>
>>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: javascript vision thing

[kai zhu]

@tj, would you or i care about nodejs/javascript if the language did not exist 
in browsers?  in fact would anyone on tc39 give a damn about javascript (aside 
from its creator) in that scenario?  as i've said before [ad nauseam], the only 
drive most of us [non-frontend-developers] have in javascript is making our 
backend-programs accessible to the masses via browsers/webviews.  javascript’s 
dominance/relevance in industry is as a *web-integration* language.  and its 
aided by its special-ability to directly serialize JSON data-structures (an 
underrated, and very useful web-integration feature), while most of its 
competitors have to rely on clumsy, hard-to-serialize classes.

there is no foreseeable future where javascript will be a better tool than 
java/c++/python/etc. for non web-related projects.  there is no foreseeable 
future where employers would hire nodejs-developers to work on non web-related 
projects.  so why does tc39 insist on pushing distracting language-features 
(clumsy java-like classes, non-integration-friendly meta-programming, static 
module-loading, etc.) for an unrealistic future-scenario that’s not going to 
happen?

kai zhu
kaizhu...@gmail.com

> On 24 Jul 2018, at 5:56 PM, T.J. Crowder  
> wrote:
> 
> On Tue, Jul 24, 2018 at 11:27 AM, kai zhu  wrote:
>> tldr - tc39 should focus more on JSON-friendly javascript-language-features
>> instead of wasting-time on hard-to-serialize classes/meta-programming.
> 
> This is a false dichotomy (the fallacy of the either/or choice). I'd
> agree we're approaching, or at, the need for the next thing after
> JSON, and that some focus on that would be a good thing. That doesn't
> mean stopping work on other good things. Perhaps you could take the
> lead on addressing the issues you run into. I'm sure constructive
> input would be welcomed.
> 
>> my problem with tc39, is that they “claim” javascript is a general-purpose
>> language (and try to design it as such), when industry-wise, its really not.
> 
> Yes, it is. Just because you don't see it that way doesn't mean others
> don't. And others have been telling you they see it differently
> repeatedly over a long period of time on this list.
> 
>> if tc39 is sincerely
>> interested in keeping javascript a dominant/relevant language in industry,
>> they should focus on *practical* (vs *academic*) features
> 
> `class` notation is practical (simplifying a common pattern and making
> it less error-prone). (I know you don't use that pattern. That's fine.
> But lots of people do, so it's practical for them whether you like the
> pattern or not.) Promises are practical (simplifying and standardizing
> callbacks, making them composable; again making them less
> error-prone). `async`/`await` is HUGELY practical, massively
> simplifying writing asynchronous code. Arrow functions, rest and
> spread, default parameter values -- all practical. (NOT trying to put
> words in your mouth, but if you were going to reply "Yes, but those
> problems could already be solved in others ways.", then: Sure, and we
> could all write assembly code, too. But it's *useful* to address these
> in the language.)
> 
> All of them are useful beyond the web. All are also useful in web programming.
> 
> I have no problem with skepticism of specific proposals. What I would
> find useful, though, would be a focus on the proposal's merits, rather
> than constant re-raising of this claim that JavaScript is a web-only
> language. You've made that claim, ad nauseum. My view is that it's
> been rejected by the list membership and by TC39, but whether that's
> true or I'm mistaken, please stop spamming the list with it. We all
> know how you feel about it.
> 
> But again: I'm sure constructive, research-based input on how to deal
> with JSON issues related to (for instance) BigInt would be welcome in
> that BigInt thread and, ideally, eventually a proposal. There's no
> need for some big conceptual argument over the course of the language
> -- that *is* a waste of time.
> 
> -- T.J. Crowder

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

Re: javascript vision thing

[kai zhu]

tldr - tc39 should focus more on JSON-friendly javascript-language-features 
instead of wasting-time on hard-to-serialize classes/meta-programming.

have you ever wondered why javascript is so popular? why you decided to become 
a nodejs/backend-javascript programmer?

javascript’s popularity is not because of any engineering/technical merits.  
its entirely a derivative of the fact that browsers have taken over the world, 
and many new software-jobs are either frontend-related, or some [glorified] 
form of backend-support for the frontend.  the business-proposition for why 
your employer hired you as a nodejs-developer (vs. php, etc…), is likely 
because they thought using the same language as their frontend-developer, would 
allow you to better *support* the needs of the frontend.  and if you can’t do a 
better job at supporting the frontend than a cheaper php/etc… developer, then 
you honestly should be *fired* (or “promoted” to management).

my problem with tc39, is that they “claim” javascript is a general-purpose 
language (and try to design it as such), when industry-wise, its really not.  
if javascript was not a browser-language, most employers could not justify 
hiring developers to create software with it.  if tc39 is sincerely interested 
in keeping javascript a dominant/relevant language in industry, they should 
focus on *practical* (vs *academic*) features that help it maintain its edge as 
a frontend/web-integration language over its competitors.

and the primary-edge javascript has over its competitors (in an industry 
dominated by web-programming), is that it can transparently 
manipulate-and-serialize JSON data-structures between frontend <-> backend 
systems, while competitors like java depend on clumsy, error-prone, 
class-constructors and custom-serializers.

kai zhu
kaizhu...@gmail.com

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

Re: proposal: Object Members

[kai zhu]

> Extend builtins, in particular - ie, `super()` allows your subclass to obtain 
> internal slots it can't otherwise get.

does extending builtins in the javascript-language even make sense, given the 
dominant industry application of it in a web-context?  as i've said before, the 
primary industry-painpoints with javascript are integration-related, namely 
serializing/reconstructing JSON data between client <-> server.  whatever 
low-level benefit you gain from extending builtins, typically is not worth the 
extra high-level integration-cost of serializing/reconstructing these custom 
data-structures to/from JSON.

p.s. - as an aside, new primitives like BigInt should have focused more on 
ease-of-use with JSON-serialization.  BigInt’s primary use-case in industry as 
i see it, is as a mechanism for JSON-serializing 64-bit integers between client 
<-> server <-> database.

kai zhu
kaizhu...@gmail.com



> On 24 Jul 2018, at 5:56 AM, Jordan Harband  wrote:
> 
> That, and that the existing builtins already impose those limitations - and 
> only `class` allows you to do those things, with them.
> 
> On Mon, Jul 23, 2018 at 3:52 PM, Ben Wiley  <mailto:therealbenwi...@gmail.com>> wrote:
> I see, so it's not that you can't do things without class as much as you can 
> impose limitations by using class. Thanks for clarifying
> 
> Le lun. 23 juill. 2018 18 h 49, Jordan Harband  <mailto:ljh...@gmail.com>> a écrit :
> When extending builtins, `super()` is the only way you can get the 
> appropriate internal slots applied to the instance. (Private fields work the 
> same way by providing a matching guarantee - that the only way someone can 
> subclass you successfully is using `class extends` and `super`)
> 
> On Mon, Jul 23, 2018 at 3:43 PM, Ben Wiley  <mailto:therealbenwi...@gmail.com>> wrote:
> What exactly can be accomplished with super that can't be accomplished 
> otherwise? I know the transpiled code is very verbose and unintuitive to read 
> if you avoid explicitly naming the base class, but I wasn't aware of new 
> capabilities that were previously impossible.
> 
> Ben
> 
> 
> Le lun. 23 juill. 2018 18 h 06, Ranando King  <mailto:king...@gmail.com>> a écrit :
> Granted about `super()`. That's the one thing I can't easily reproduce. 
> However, barring those internal slots, I can reproduce the functionality of 
> `super` and the checks performed as a result of the internal slots, all in 
> ES6. As for built-ins, I can easily and properly extend builtins without 
> `class` since ES6 officially has `Object.setPrototypeOf()`. If you don't 
> think it's possible, you should take a close look at what I'm doing in the 
> repl.it <http://repl.it/> link from my first post.
> 
> As for whether or not the sugary nature of `class` is a good thing, it really 
> is a matter of opinion. I just happen to be of the persuasion that since 
> there's literally no construct that `class` can produce that I cannot 
> reproduce by other means, then that means the `class` keyword (even in light 
> of `super`) is little more than syntactic sugar. As such, we shouldn't be so 
> hasty to turn an Object Oriented Prototype Based language into an Object 
> Oriented Class Based language. The only way to do that reasonably is to 
> ensure that whatever you can construct with `class` can always be 
> equivalently constructed without it.
> 
> Here's a more logical argument instead. Even if there are subtle differences 
> between `class` constructors and object factory functions, providing an 
> isolated path specific to `class` is likely to lead to situations very 
> similar to what happens when an open source package gets forked. Eventually, 
> the difference between the two paths may become so great that one is 
> eventually abandoned (by developers) in favor of the other. This is only a 
> valid argument because the power of ES is in it's simplicity. It's like 
> building a house with wood, nails, sheetrock, etc... (JS) vs. building a 
> house with pre-fabricated parts (class-based languages).
> 
> Don't get me wrong. The `class` keyword is a great thing. It simplifies the 
> production of creating object factories with prototypes. As I understand it, 
> that was the purpose. Let's not make the mistake of allowing something to be 
> done with `class` that cannot be reasonably reproduced without it. The moment 
> we do that, we're diverging from the intended purpose of `class`.
> 
> 
> 
> On Mon, Jul 23, 2018 at 4:17 PM Jordan Harband  <mailto:ljh...@gmail.com>> wrote:
> Extend builtins, in particular - ie, `super()` allows your subclass to obtain 
> internal slots it can't otherwise get.
> 
> Even if `class` were just sugar, I don't think I see the argument that that's 

Re: Promise capability support

[kai zhu]

my use-case is the exact opposite.  in integration-level javascript,
its impractical to have independent rejectors/error-handlers for
dozens of integrated-components.  its much easier to debug/refactor
integration-code with a single, universal rejector/error-handler (all
it does is log the error-stack and return a 404/500 to the
server-request, or crash the app if client-side).

on server-side, you can't do much except 404/500 if the db-request
times-out, JSON.parse fails, etc.

on client-side, crashing the app (and notifying user an error occured,
and retry the request)  is pretty much the only thing you can do when
the server 404/500's.

On 7/20/18, Bob Myers  wrote:
> I've used this pattern exactly twice in the large-scale app I'm working on
> now.
> One of those I was able to eliminate after I thought harder about the
> problem.
> The other I eventually replaced with the following kind of pattern:
>
> ```
> function createPromise(resolver, rejector) {
>   return new Promise((resolve, reject) {
> resolver.then(resolve);
> rejector.then(reject);
> });
> }
> ```
>
> Obviously the way this works it that to create a promise "controllable"
> from "the outside",
> you create your own resolver and rejector promises to pass to
> `createPromise`,
> such that they trigger when you need them to.
> To put it a different way, instead of getting back and passing around
> deferred-like objects,
> which seems to be a massive anti-pattern to me,
> the client creates their own promise-controlling promises designed to
> trigger at the right time.
>
> Bob
>
> On Fri, Jul 20, 2018 at 9:07 AM Jordan Harband  wrote:
>
>> I don't think the Deferred pattern is a good primitive to have in the
>> language, and it's a pretty trivial primitive to write yourself if you
>> need
>> it.
>>
>> On Thu, Jul 19, 2018 at 6:13 PM, Isiah Meadows 
>> wrote:
>>
>>> Sometimes, it's *very* convenient to have those `resolve`/`reject`
>>> functions as separate functions. However, when logic gets complex
>>> enough and you need to send them elsewhere, save a continuation, etc.,
>>> it'd be much more convenient to just have a capability object exposed
>>> more directly rather than go through the overhead and boilerplate of
>>> going through the constructor with all its callback stuff and
>>> everything.
>>>
>>> It's surprisingly not as uncommon as you'd expect for me to do this:
>>>
>>> ```js
>>> let resolve, reject
>>> let promise = new Promise((res, rej) => {
>>> resolve = res
>>> reject = rej
>>> })
>>> ```
>>>
>>> But doing this repeatedly gets *old*, especially when you've had to
>>> write it several dozen times already. And it comes up frequently when
>>> you're writing lower-level async utilities that require saving promise
>>> state and resolving it in a way that's decoupled from the promise
>>> itself.
>>>
>>> -
>>>
>>> So here's what I propose:
>>>
>>> - `Promise.newCapability()` - This basically returns the result of
>>> [this][1], just wrapped in a suitable object whose prototype is
>>> %PromiseCapabilityPrototype% (internal, no direct constructor). It's
>>> subclass-safe, so you can do it with subclasses as appropriate, too.
>>> - `capability.resolve(value)` - This invokes the implicit resolver
>>> created for it, spec'd as [[Resolve]].
>>> - `capability.reject(value)` - This invokes the implicit rejector
>>> created for it, spec'd as [[Reject]].
>>> - `capability.promise` - This returns the newly created promise.
>>>
>>> Yes, this is effectively a deferred API, but revealing constructors
>>> are a bit too rigid and wasteful for some use cases.
>>>
>>> [1]: https://tc39.github.io/ecma262/#sec-newpromisecapability
>>>
>>> -
>>>
>>> Isiah Meadows
>>> m...@isiahmeadows.com
>>> www.isiahmeadows.com
>>> ___
>>> 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