Re: Optional Curly Braces in JavaScript

On Sun, Nov 3, 2019 at 1:11 PM Ed Saleh wrote: > Yes, I know JavaScript is influenced by the C syntax family, which is my > favorite style. However, what I pushed for here is kind of merging of 2 > programming languages families. We here are talking good attributes from > Python and adding it to

Re: Optional Curly Braces in JavaScript

> C# had these feature but still the scientific community went for > Python and not C#. C# is a explicitly compiled language. And a Windows language. (Mono is irrelevant, it would be a huge dependency.) Next? ___ es-discuss mailing list

Re: Optional Curly Braces in JavaScript

C# had these feature but still the scientific community went for Python and not C#. JavaScript today has almost all the features python has and more and still it's not as popular as Python for prototyping, algorithms, and AI. From: es-discuss on behalf of

Re: Optional Curly Braces in JavaScript

> People are more inclined to go for readable and less verbose > languages You keep saying that's *the reason* scientific and data-scientific community prefers Python but haven't provided evidence, continuing to sidestep: ● Python's intrinsic support for large numbers ● Python's strong

Re: Optional Curly Braces in JavaScript

The TC39 efforts are already quite diluted to add major changes to the language which, no offense, don't really add anything of value. OP if you really want a whitespaced language for the browser check Imba: https://www.imba.io/ It's not only a programming language but also a React replacement.

Re: Optional Curly Braces in JavaScript

I really like the easy on the eye, readable and simple style of Python and though to bring some of these attributes to JavaScript. People are more inclined to go for readable and less verbose languages. From: es-discuss on behalf of Ed Saleh Sent: Sunday,

Re: Optional Curly Braces in JavaScript

Yes, I know JavaScript is influenced by the C syntax family, which is my favorite style. However, what I pushed for here is kind of merging of 2 programming languages families. We here are talking good attributes from Python and adding it to JavaScript. From: Ed

Re: Optional Curly Braces in JavaScript

@Bergi: Thanks. This is true only as long as the semantics of significant- whitespace blocks are supposed to stay exactly the same as the semantics of braced blocks. If this proposal is purely syntactical, you are right, but then, I would fail to see the point of this endeavor. @Ed: Maybe

Re: Optional Curly Braces in JavaScript

Ok, no problem. I know the committee doesn't add features easily, but starting a discussion is a good first step. From: es-discuss on behalf of Bergi Sent: Sunday, November 3, 2019 4:05:36 PM To: es-discuss@mozilla.org Subject: Re: Optional Curly Braces in

Re: Optional Curly Braces in JavaScript

Hi! > If it's possible in JavaScript to have `:`, and enable significant spacing, > that would be great. > > Why you don't *want* to? Your argument for significant whitespace seems to be that the simplicity of Python is great. However, adding an alternative block syntax to JavaScript would fail

Re: Optional Curly Braces in JavaScript

Hi, We can convert the curly braces less style back to curly braces blocks when minifying. We can enforce that style also through linting. Making this new style of using colon spacing for block would be an option to use a certain situations. It basically like `if(foo) bar()` and `if

Re: Optional Curly Braces in JavaScript

Hi! > Note that significant whitespace greatly minimizes the yields of minification Why would it? Nothing would prevent a minifier from changing significant whitespace into braced blocks - just like today, they omit semicolons where possible and remove braces around single-statement blocks.

Re: Optional Curly Braces in JavaScript

Note that significant whitespace greatly minimizes the yields of minification as well, which doesn't matter much for languages like Python, but starts to matter as soon as you're forced to send your source code over the network, expecting something to appear on the screen in a few hundred

Re: Optional Curly Braces in JavaScript

If it's possible in JavaScript to have `:`, and enable significant spacing, that would be great. From: es-discuss on behalf of Ed Saleh Sent: Sunday, November 3, 2019 3:34:09 PM To: Bergi ; es-discuss@mozilla.org Subject: Re: Optional Curly Braces in

Re: Optional Curly Braces in JavaScript

Why you don't *want* to? I didn't force you to like my proposal. I am just posting my ideas for feedback, not see who wants and doesn't want to like it. From: es-discuss on behalf of Bergi Sent: Sunday, November 3, 2019 3:17:11 PM To: es-discuss@mozilla.org

Re: Optional Curly Braces in JavaScript

Hi Ed! > Update to the proposal: > > Since we can't make spaces in JavaScript, the best we can do is use '_' > instead. You misunderstood. We *could* make use of significant whitespace in JavaScript (enabled by the `:` instead of a brace after a statement) - we just don't *want* to. That said,

Re: Optional Curly Braces in JavaScript

Any identifier that can implement this feature is great. From: es-discuss on behalf of Ed Saleh Sent: Sunday, November 3, 2019 2:49:35 PM To: Sanford Whiteman ; es-discuss Subject: Re: Optional Curly Braces in JavaScript If it's not possible to get around

Re: Optional Curly Braces in JavaScript

If it's not possible to get around that, double underscore `__` or more `_{2,}` can be used. From: es-discuss on behalf of Ed Saleh Sent: Sunday, November 3, 2019 2:47:13 PM To: Sanford Whiteman ; es-discuss Subject: Re: Optional Curly Braces in JavaScript

Re: Optional Curly Braces in JavaScript

How is it a valid identifier? I guess the `_` in my case would be used as a statement, not as a function and the JavaScript compiler can somehow distinguish between the different contexts depending on the surrounding identifiers. To my knowledge `_` is used to make numbers more readable, e.g.

Re: Optional Curly Braces in JavaScript

The single character _ *is already a valid identifier* as Ron said. And not an obscure one (not that that would matter) but rather *the global object used by the Underscore library*. You might as well be using $ here and trying to convince people to stop using it as the top level of

Re: Optional Curly Braces in JavaScript

`_` is better than `,` because `_` is the closest thing possible to empty space, it could. It could even be represented as empty space when it's written down, and it could come at the beginning or at the end, it's also more appropriate for repeatation, `__` is more appropriate than `,,`.

Re: Optional Curly Braces in JavaScript

The '_' isn't necessary for chaining expressions, as ',' would already suffice: ``` if (foo==2) bar(), bar2(); ``` Also, '_' is already a valid expression/identifier. While I'm not generally a fan of eliding braces from everything, I have expressed interest in evaluating something like

Re: Optional Curly Braces in JavaScript

Update to the proposal: Since we can't make spaces in JavaScript, the best we can do is use |_` instead. We will also git rid of `:` after statement in the old version as `_` is enough indication and it's more compatible with our current curly braces syntax. Final result: ``` if (foo==2) _

Re: Optional Curly Braces in JavaScript

Update to the proposal: Since we can't make spaces in JavaScript, the best we can do is use '_' instead. We will also git rid of ':' after statement in the old version as '_' is enough indication and it's more compatible with our current curly braces syntax. Final result: ``` if (foo==2) _

Re: Optional Curly Braces in JavaScript

> 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). Browsers (WPWG, not this group) tried WebSQL. It failed because there wasn't a competitive bake-off with any other implementations _besides_

Re: Optional Curly Braces in JavaScript

> 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

Re: Optional Curly Braces in JavaScript

> 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

Re: Optional Curly Braces in JavaScript

Python is so broadly used in those fields due to good library support, not just ease of language use. But since that discussion is pretty off-topic, I'll leave it there. On Sat, Nov 2, 2019 at 21:33 Ed Saleh wrote: > I don't see any reason why Python is widely used in math and science, and >

Re: Optional Curly Braces in JavaScript

I don't see any reason why Python is widely used in math and science, and specially AI, other than this reason. It's easy to write and prototype in. From: Jordan Harband Sent: Saturday, November 2, 2019 9:23:31 PM To: Ed Saleh Cc: Bergi ; es-discuss ; kai zhu

Re: Optional Curly Braces in JavaScript

I don’t think the obstacle to JavaScript becoming more widespread is mandatory curly braces, nor do i think any part of python’s popularity is due to optional curly braces. Separately, how are you measuring “widespread”? One measurement might be, for example, “how many computers is it used on”,

Re: Optional Curly Braces in JavaScript

Hi Kai Zhu, We can enforce curly braces through "good practice" JavaScript documentation style and eslint style. Making braceless JavaScript feature doesn't make it the best style to use, it just give more flexibility. And yes Jordan, it should actually be enforced to use curly braces in actual

Re: Optional Curly Braces in JavaScript

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

Re: Optional Curly Braces in JavaScript

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

Re: Optional Curly Braces in JavaScript

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

Optional Curly Braces in JavaScript

Hello Everyone, I would like to propose allowing curly braces to be optional in JavaScript. Example: ``` function foo(){ bar() } ``` can be written as: ``` function foo(): bar() ``` Or #2: ``` function foo(): {bar()} {bar2()} ``` Or #3: ``` function foo(): _ bar() _ bar2() ``` Or #4: ```

Re: function invocation with just commas for explicit undefined optional arguments in the middle

On 11/1/19 5:10 AM, Cyril Auburtin wrote: yes true, it's even more annoying with eslint, you have to configure it with https://eslint.org/docs/rules/no-unused-vars#argsignorepattern for example That's talking about function _declarations_, whereas the original proposal in this thread is

Re: function invocation with just commas for explicit undefined optional arguments in the middle

Using `undefined` is readable, it's just not as short. But that's my point. Readability should normally trump "shortness" in case they conflict, in my mind, (while both are desirable) simply for the following reason: if something is accidentally misread, it can cause a bug when used or modified,

Re: function invocation with just commas for explicit undefined optional arguments in the middle

yes true, it's even more annoying with eslint, you have to configure it with https://eslint.org/docs/rules/no-unused-vars#argsignorepattern for example To be fair I considered this case mostly for `Array.from({length: n}, (,i) => i)`, but it's easier to forget that comma. What's preferable is a

Re: Proposal: Discarding specific element when importing/re-exporting module

It's also possible to split that large 'A' file in 2, and have a possible third file merging them ```js export * from './numbers.js' export * from './A-without-numbers.js' ``` On Sun, Oct 27, 2019 at 6:39 AM Sm In wrote: > # Proposal: `except` clause in ModuleItem > > Inspired by [Haskell’s

Re: function invocation with just commas for explicit undefined optional arguments in the middle

I'm not sure I find the reduced readability argument compelling on this one. The alternatives suggested (throwaway variables or crowding meaningful parameters with `undefined`) don't get clean scores on that front either, IMO. Simply eliding a parameter seems like a nice example of

Re: function invocation with just commas for explicit undefined optional arguments in the middle

I proposed it a long time ago https://esdiscuss.org/topic/ignoring-arguments but I agree with Tab Atkins nowadays, it would hurt readability On Wed, Oct 30, 2019 at 9:34 AM Naveen Chawla wrote: > I tend to agree and one thing I like in good code is "glanceability" - > > the ability to "glance"

Re: function invocation with just commas for explicit undefined optional arguments in the middle

I tend to agree and one thing I like in good code is "glanceability" - the ability to "glance" and see what's going on. If I have doStuff(bar,, foo,, far) vs doStuff(bar, foo,, far) they don't look too different, but really they are. I normally break params into separate lines so I wouldn't

Re: function invocation with just commas for explicit undefined optional arguments in the middle

On Tue, Oct 29, 2019 at 9:06 AM manuelbarzi wrote: > ``` > fun('a', 'b',, 'd',, 'f') > ``` While this does technically match up with arrays, I find the the array behavior unreadable and unintuitive (especially with the exception for the final comma), and I'd prefer that syntax quirk not spread

function invocation with just commas for explicit undefined optional arguments in the middle

hi not sure if this proposal is/was already in discussion. didn't find it. it's about having the chance to invoke a function with just commas where explicit undefined optional arguments at the beginning or in the middle (not the last one, so not to interfere with trailing commas

Proposal: Discarding specific element when importing/re-exporting module

# Proposal: `except` clause in ModuleItem Inspired by [Haskell’s import statement](https://wiki.haskell.org/Import ) ## Concept Introduction Let’s say we have module A: ```js // A.js export const zero = 0; export const one = 1; export const two = 2; export

Re: Conditional await, anyone?

> You still seem to be misunderstanding what the execution order difference is about. If to stop this thread you need me to say I am confused about anything then fine, "I am confused", but if you keep changing my examples to make your point then this conversation goes nowhere, so I am officially

Re: Conditional await, anyone?

On Sat, Oct 12, 2019 at 7:19 AM Andrea Giammarchi wrote: > in order to work, `await` must be executed in an async scope/context (either > top level or within a closure). > > In such case, either somebody is awaiting the result of that `async` > execution, or the order doesn't matter. That's

Re: Re: Modify Promise.all() to accept an Object as a parameter

On Fri, Oct 11, 2019 at 9:53 PM Jacob Bloom wrote: > What about special handling for Maps? Maybe something like > > ``` > const requests = new Map(); > requests.set('reqA', fetch('...')); > requests.set('reqB', fetch('...')); > const responses = await Promise.all(requests); > console.log( >

Re: Modify Promise.all() to accept an Object as a parameter

The RSVP library uses Promise.hash, which seems sensible enough that I'm surprised no-one has mentioned or suggested it here. -- Dammit babies, you've got to be kind. On Mon, 14 Oct 2019 at 09:17, Michał Wadas wrote: > Established name is Promise.properties > > On Mon,

Re: Modify Promise.all() to accept an Object as a parameter

Established name is Promise.properties On Mon, 14 Oct 2019, 09:29 Cyril Auburtin, wrote: > maybe a naming like: `Promise.allObject` > > ```js > Promise.allObject = obj => { > if (obj && !obj[Symbol.iterator]) { > return Promise.all( > Object.entries(obj).map(async ([k, v]) => [k,

Re: Modify Promise.all() to accept an Object as a parameter

maybe a naming like: `Promise.allObject` ```js Promise.allObject = obj => { if (obj && !obj[Symbol.iterator]) { return Promise.all( Object.entries(obj).map(async ([k, v]) => [k, await v]) ) .then(Object.fromEntries); } return Promise.all(obj); } var delay = t => new

Re: Modify Promise.all() to accept an Object as a parameter

Maybe Promise.join(object)? Also, if a map is passed (or any iterable), it should be joined into a map. At the most basic level: ```js Promise.join = (o) => { let isMap = o[Symbol.iterator] != null let ps = ( isMap ? Array.from : Object.entries )(o) let ks = ps.map(p =>

Re: Modify Promise.all() to accept an Object as a parameter

OP probably means he would like Promise.all to return an object as well, if an object if given It's possible to hack an object to be iterable, but Promise.all already return an array unfortunately On Sun, Oct 13, 2019 at 7:16 PM Boris Zbarsky wrote: > On 10/12/19 12:52 AM, Jacob Bloom wrote: >

Re: Modify Promise.all() to accept an Object as a parameter

On 10/12/19 12:52 AM, Jacob Bloom wrote: const responses = await Promise.all(requests); As opposed to: const responses = await Primise.all(requests.values()); which works right now? -Boris ___ es-discuss mailing list es-discuss@mozilla.org

Re: Conditional await, anyone?

in order to work, `await` must be executed in an async scope/context (either top level or within a closure). In such case, either somebody is awaiting the result of that `async` execution, or the order doesn't matter. The following two examples produce indeed the very same result: ```js (async

Re: Re: Modify Promise.all() to accept an Object as a parameter

What about special handling for Maps? Maybe something like ``` const requests = new Map(); requests.set('reqA', fetch('...')); requests.set('reqB', fetch('...')); const responses = await Promise.all(requests); console.log( responses.get('reqA'), responses.get('reqB'), ); ``` ...which would

Re: Conditional await, anyone?

On Fri, Oct 11, 2019 at 1:15 AM Andrea Giammarchi wrote: > Again, the `await?` is sugar for the following: > > ```js > const value = await? callback(); > > // as sugar for > let value = callback(); > if ('then' in value) > value = await value; > ``` Okay, so that has the "you can't predict

Re: Re: Modify Promise.all() to accept an Object as a parameter

Promise.all(Object.values(myObjWithPromiseValues)).then(...) On Fri, Oct 11, 2019 at 10:22 AM Jordan Harband wrote: > The current API accepts an *iterable*, which means any object that has > `Symbol.iterator`, such as an array or a Set. > > Throwing when it receives a non-iterable object is an

Re: Re: Modify Promise.all() to accept an Object as a parameter

The current API accepts an *iterable*, which means any object that has `Symbol.iterator`, such as an array or a Set. Throwing when it receives a non-iterable object is an important tool to catch bugs. If Promise.all was made to accept a non-iterable object as well, I suspect many bugs would go

Re: Re: Modify Promise.all() to accept an Object as a parameter

Back when async/await was introduced I struggeled quite a bit with promises arrays that have conditional promises. RxJS is moving from array only support in theirs operators to objects too, there seems to be an actual trend going on. Is there any reason

Re: Conditional await, anyone?

Again, the `await?` is sugar for the following: ```js const value = await? callback(); // as sugar for let value = callback(); if ('then' in value) value = await value; ``` but since I've stated already I have no interest anymore in this proposal, we can also stop explaining to each others

Re: Conditional await, anyone?

On Wed, Oct 9, 2019 at 11:17 PM Andrea Giammarchi wrote: > > What's the order of the logs? > > Exactly the same, as the `await?` is inevitably inside an `async` function > which would grant a single microtask instead of N. I think you're misreading my example? Check this out:

Re: Conditional await, anyone?

> What's the order of the logs? Exactly the same, as the `await?` is inevitably inside an `async` function which would grant a single microtask instead of N. Example: ```js async function tasks() { await? maybeAsync(); await? maybeAsync(); await? maybeAsync(); } tasks(); ``` If

Re: Conditional await, anyone?

On Wed, Oct 9, 2019 at 12:08 AM Andrea Giammarchi wrote: > I don't know why this went in a completely unrelated direction so ... I'll > try to explain again what is `await?` about. Nah, we got it. Our complaint was still about the semantics. > ```js > const value = await? callback(); > > // as

Re: Conditional await, anyone?

Hi! First, experiences of this guy https://medium.com/@bluepnume/intentionally-unleashing-zalgo-with-promises-ab3f63ead2fd seem to refute the problematicity of zalgo. Second, I actually have the use case of this pattern (though actually it's not a use case for a new syntax). In Amber

Re: Conditional await, anyone?

I had a similar example in real-world code, but it was just to merge sync and async into the same code path. I handled it by using generators and basically running them myself: https://github.com/isiahmeadows/mithril-node-render/blob/v2/index.js#L195-L206 In either case, I'm not sure it's worth

Re: Conditional await, anyone?

I don't know why this went in a completely unrelated direction so ... I'll try to explain again what is `await?` about. My first two examples show a relevant performance difference between the async code and the sync one. The async code though, has zero reasons to be async and so much slower.

Re: Conditional await, anyone?

Have to agree, mixing sync and async code like this looks like a disaster waiting to happen. Knowing which order your code will be executed in might seem not so important for controlled environments where micro optimisations are attractive, but thinking about trying to track down a bug through

Re: Conditional await, anyone?

I'm not sure I understand the intended use-case here. If the author knows the function they're calling is async, they can use `await` normally. If they know it's not async, they can avoid `await` altogether. If they have no idea whether it's async or not, that means they just don't understand

Re: Conditional await, anyone?

> Sure thing, engines might infer returned values in some hot code and skip the microtask dance once it's sure some callback might return values that are not promises, but what if developers could give hints about this possibility? Engines can't do this, because it would change the observable

Conditional await, anyone?

When developers use `async` functions, they'll likely also await unconditionally any callback, even if such callback could return a non promise value, for whatever reason. Engines are great at optimizing stuff, but as of today, if we measure the performance difference between this code: ```js

Re: Why globalThis instead of something intuitive like globalObject, systemGlobal, or globalEntity?

On 10/7/19 1:56 PM, #!/JoePea wrote: Who's going to write code like that anyways? In the general form of "function from a navigated-away-from document runs because it's called by some script from outside the document", I've seen this come up a number of times in web browser bug reports.

Re: Why globalThis instead of something intuitive like globalObject, systemGlobal, or globalEntity?

Who's going to write code like that anyways? Everyone's moving to ES modules, where `this` for accessing the global is just `undefined`. It's highly unlikely that any concept other than "global object" will ever be conceived by the vast majority of users, especially future users. On Fri, Oct 4,

Re: Why globalThis instead of something intuitive like globalObject, systemGlobal, or globalEntity?

I didn't see it. For some reason my gmail thread split into two separate threads, and I read one before the other. On Mon, Oct 7, 2019 at 7:14 AM Boris Zbarsky wrote: > > On 10/7/19 1:29 AM, #!/JoePea wrote: > > I've never written any sort of code that can prove or verify any of > > what you all

Re: Why globalThis instead of something intuitive like globalObject, systemGlobal, or globalEntity?

On 10/7/19 1:29 AM, #!/JoePea wrote: I've never written any sort of code that can prove or verify any of what you all are talking about. Mind showing code samples? Did you not see https://mail.mozilla.org/pipermail/es-discuss/2019-October/053033.html ? -Boris

Re: Why globalThis instead of something intuitive like globalObject, systemGlobal, or globalEntity?

Ah, this thread got forked from the other one, which has a code sample. Taking a look at that... On Sun, Oct 6, 2019 at 10:29 PM #!/JoePea wrote: > > I never knew any of all that stuff you have all mentioned, and as an > end user, I don't think I would ever need to know. To me, I use > `window`

Re: Why globalThis instead of something intuitive like globalObject, systemGlobal, or globalEntity?

I never knew any of all that stuff you have all mentioned, and as an end user, I don't think I would ever need to know. To me, I use `window` as a global object, and it has never been more than that. I've never written any sort of code that can prove or verify any of what you all are talking

Re: Why globalThis instead of something intuitive like globalObject, systemGlobal, or globalEntity?

On 10/6/19 2:58 PM, Raul-Sebastian Mihăilă wrote: Also let's not forget that the WindowProxy behavior contradicts the JS object model in that the non-configurable 'something' own property of the window proxy is removed. There is a proposal for addressing that. Firefox has been shipping it

Why globalThis instead of something intuitive like globalObject, systemGlobal, or globalEntity?

Also let's not forget that the WindowProxy behavior contradicts the JS object model in that the non-configurable 'something' own property of the window proxy is removed. ___ es-discuss mailing list es-discuss@mozilla.org

Re: Why globalThis instead of something intuitive like globalObject, systemGlobal, or globalEntity?

On 10/4/19 2:39 PM, #!/JoePea wrote: but the global `this` you captured still has the same identity as the new reference. Interesting, I never knew that. Do you have a code sample to show how to detect or prove that? Sure. The following code logs "true, 5, 5, 5, 5, true, undefined,

[proposal-idea] Variable decorators

Currently we can implement things like "reactive variables" and "reactive computations". Contrived example: ```js import {rv, computation} from './reactive-variable' const count = rv(0) // read the value console.log(count()) // 0 // set the value count(1) console.log(count()) // 1 //

Re: Why globalThis instead of something intuitive like globalObject, systemGlobal, or globalEntity?

> but the global `this` you captured still has the same identity as the new > reference. Interesting, I never knew that. Do you have a code sample to show how to detect or prove that? On Sat, Sep 21, 2019 at 9:05 PM Isiah Meadows wrote: > > If you look in the proposal's repo, they explain the

Re: Re: Modulo Operator %%

Now how does this get to becoming a proposal? Is there a TC39 member that has seen this and will introduce it to the committee? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Custom Elements in Templates

You'd have better luck in https://discourse.wicg.io than here. This is about the ECMAScript spec and JavaScript the language, not anything related to the web platform at large. On Tue, Sep 24, 2019 at 09:55 Randy Buchholz wrote: > I’m putting a custom element in a template and then “selecting”

Custom Elements in Templates

I'm putting a custom element in a template and then "selecting" it out to Window level. It seem to loose its identity as a custom element. ``` // In page class MyElement extends HTMLElement { constructor() { super(); } get Field() { return

Re: Why globalThis instead of something intuitive like globalObject, systemGlobal, or globalEntity?

If you look in the proposal's repo, they explain the rationale behind the identifier: https://github.com/tc39/proposal-global/ Here's a short summary: `globalThis` is the same value you get from evaluating `this` in the global scope of a sloppy mode script. This is subtly different than a "global

Re: Why globalThis instead of something intuitive like globalObject, systemGlobal, or globalEntity?

This question is more appropriate for the proposal repo, in which a very lengthy naming document will hopefully answer all of your questions: https://github.com/tc39/proposal-global/blob/master/NAMING.md Please address all further comments or replies on this topic to the proposal repo. Thanks!

Why globalThis instead of something intuitive like globalObject, systemGlobal, or globalEntity?

I know it may be too late for this, but I imagine `globalThis` can bring confusion to beginners, especially ESL beginners. Things like `globalObject`, `systemGlobal`, or `globalEntity` would've been more intuitive; they make sense in plain English. Well anyways, have a good weekend! - Joe

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

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

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

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

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

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: /\-/:

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

Nit: Acorn's *output* is based on Esprima. Its code is *not* and hasn't been for a few years now. It started a fork of Esprima, but it wasn't long before it was rewritten the first time. - Isiah Meadows cont...@isiahmeadows.com www.isiahmeadows.com On Mon, Sep 16, 2019 at 1:58 AM kai zhu

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

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

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

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

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

Happy to see standard ast in binary ast proposal. For compiler, it can have a "slow" mode when parsing with this parser API and still use fast code generation in other cases. But unfortunately it seems there are much more work than I think to provide such an API. David Teller 于 2019年9月15日周日

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

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

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

I do want to note a couple things here, as someone familiar with the implementation aspect of JS and programming languages in general: 1. The HTML and CSS parsers (for inline style sheets) have to build a full DOM trees for each anyways just to conform to spec, so they can't just, say, parse

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

I had a few goes with making a JS sandbox. I also created a safe DOM environment that allowed safe manipulation of innerHTML etc JS sandbox with regular expressions http://www.businessinfo.co.uk/labs/jsreg/jsreg.html JS sandbox and safe DOM environment

Re: Stage 0 proposal: specifying concurrency for "for...of" loops potentially containing "await" statements

> > There's a tradeoff here. > > If it's an extension of `for...of`, it's much clearer for users. If it's > a method of `Promise`, it's much more extensible. > > Perhaps it could be a little bit of both? > > Maybe something like: > ``` > for(item of items : Scheduler.limit(5)) { > // ... > } >

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

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

<    1   2   3   4   5   6   7   8   9   10   >