Re: Support underscores in numbers
Oops, I'm an idiot and didn't see this. On 26/07/2017 21:49:11, Logan Smyth wrote: There is currently an active proposal for this: https://github.com/tc39/proposal-numeric-separator [https://github.com/tc39/proposal-numeric-separator] On Wed, Jul 26, 2017 at 1:47 PM, Alexander Craggs mailto:alexan...@debenclipper.com]> wrote: Large number are hard to read in JavaScript, is 2384923842 over a billion? Or just several hundred million. One solution to this some languages have used is to allow underscores within numbers. You can immediately recognise 2_384_923_842 is a number in the billions, rather than millions. It would be nice to have such delimiters in large numbers in JavaScript as well, and I don't think it would be breaking. ___ 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
Support underscores in numbers
Large number are hard to read in JavaScript, is 2384923842 over a billion? Or just several hundred million. One solution to this some languages have used is to allow underscores within numbers. You can immediately recognise 2_384_923_842 is a number in the billions, rather than millions. It would be nice to have such delimiters in large numbers in JavaScript as well, and I don't think it would be breaking.___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Add an easier method for slicing and stepping strings and arrays
In which case, perhaps change this proposal to .slice(start, end, step)___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Migrating to a better communication tool
> requires browser use Nope. Both Discourse + NodeBB allow the ability to use them as a mailing list. Thus, they require nothing more to use than the current system. (You require a browser to sign up, but mailing lists here require the same thing as well). > long term archival I would argue it is significantly simpler with a forum as opposed to emails. For NodeBB something like the following should be used: ``` mongoexport --db nodebb --out dump.json ``` JSON being a significantly more supported format than the mail format. > muting can be done in clients Can't ignore by tag and my clients don't support it. So what if this is just the same? We've discussed numerous other advantages it would provide > we can have both I honestly think having both forum and mailing list will just result in disjointed conversations. They either need to mirror each other or we need to use just one. If hosting is an issue, then I'd be willing to provide funding / host it myself. Any concerns about it going down could be sorted just with a daily cron job to back everything up to some publicly accessible dump hosted by another party. On 26/07/2017 13:53:12, T.J. Crowder wrote: On Wed, Jul 26, 2017 at 1:38 PM, Sebastian Malton mailto:sebast...@malton.name]> wrote: > I propose something list how rust does it. They have a git repo for > RFCs and that allows people to to star it or just follow the ones > that they want to follow. You can do that with the github repos used by TC39 proposals. This thread isn't about proposals/RFCs, it's about moving the general conversations in es-discuss away from email into Something Else. But again, this has [all been discussed][1]. I don't see anything in that thread about whether it was actually discussed at the July 2015 meeting(s) as Brendan Eich suggested; I don't find anything relevant in the meeting notes for all three meetings if I search for "es-discuss", "email", "mailing", or "discourse". -- T.J. Crowder [1]: https://esdiscuss.org/topic/move-es-discuss-to-discuss-webplatform-org [https://esdiscuss.org/topic/move-es-discuss-to-discuss-webplatform-org] ___ 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
Migrating to a better communication tool
Thought I'd move the topic of a new communication tool to it's own thread. So that it doesn't pollute the (already polluted) removal of language features thread. I took agree with Mark, I think it's time to move away from a mailing list and the obvious choice for discussions like this is a forum. Discourse is one option, but I'd also like to put our NodeBB[0] as another option. Thoughts of how it might be better than the current mailing list: - Doesn't pollute my inbox, option to subscribe and unsubscribe to particular threads. - Stops replies from showing up on some mail clients (https://puu.sh/wThmq/ae276dd806.png) - Universal formatting. esdiscuss.org seems to break formatting sometimes (or put it in an attachement). Negatives: - People who already have a good system setup for mailing lists will have to get used to working with a forum system. - Will require either a OAuth account (Github perhaps?) or an extra username and password. [0] https://github.com/NodeBB/NodeBB I hope more people read and search https://esdiscuss.org [https://esdiscuss.org/]/ and engage with history instead of coming as if to a blank slate. In all fairness, es-discuss is rather ancient in the way it works. I personally would recommend es-discuss coming up with a better way to keep track of its threads. The current setup is rather confusing, imo. FWIW, I personally would recommend Discourse [https://www.discourse.org/]. I agree with you on the same topics coming up constantly though.___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: FW: Removal of language features
I think version interoperability is a must in a world of Webpack & Browserify. On 25/07/2017 21:12:58, doodad-js Admin wrote: * How are you going to deal with scenarios that don't have extensions, e.g. REPL or inline JS. For inline, that’ll be: ... For REPL, I don’t know... I didn’t think about this one :-) It should be based of the content of the page. And I don’t know if we should allow to mix different versions together. That’s things we’ll have to clarify. * Are extensions going to be released often, or is this going to be a one time thing? Just at another new major revision of JS, which should not happen before a long time. * would it make more sense to start on js7 instead of js2 No, because ES6, ES7, ... are still JS 1. From: Alexander Craggs [mailto:alexan...@debenclipper.com] Sent: Tuesday, July 25, 2017 3:54 PM To: doodad-js Admin ; es-discuss@mozilla.org Subject: Re: FW: Removal of language features I'm sorry, I missed that suggestion. That definitely sounds significantly better than a new MIME type. Although two thoughts I have are: - How are you going to deal with scenarios that don't have extensions, e.g. REPL or inline JS. - Are extensions going to be released often, or is this going to be a one time thing? For example, would we increment the version number with the current JS version (js6, js7 etc) and if so, would it make more sense to start on js7 instead of js2?___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: FW: Removal of language features
I'm sorry, I missed that suggestion. That definitely sounds significantly better than a new MIME type. Although two thoughts I have are: - How are you going to deal with scenarios that don't have extensions, e.g. REPL or inline JS. - Are extensions going to be released often, or is this going to be a one time thing? For example, would we increment the version number with the current JS version (js6, js7 etc) and if so, would it make more sense to start on js7 instead of js2? On 25/07/2017 20:41:33, doodad-js Admin wrote: * 1. In terms of including it in
Re: Removal of language features
Some thoughts on using MIME types to distinguish between versions: 1. In terms of including it in
Re: JavaScript Versioning
Huh, in which case I will!
What are your thoughts on the non-error message part of this proposal?
On 23/07/2017 06:34:48, Jordan Harband wrote:
Error messages 1) are unspecified, 2) change all the time, 3) vary by language,
4) vary across browser/engine implementations. There is zero reason that any
error message couldn't be changed, and in fact, many browsers do improve them
over time.
I'd say before believing it can't be done, try filing tickets on Chromium,
Webkit, SpiderMonkey, and Chakra, and see what the response is - you may get a
more favorable response than you think.
On Sat, Jul 22, 2017 at 10:19 PM, Alexander Craggs mailto:alexan...@debenclipper.com]> wrote:
(Apologies for the double email Jordan, I accidentally replied to just you, not
es-discuss as well. I'm new to this whole mailing list thing.)
Apologies, that was a bad example. I was more considering "use strict" to be
breaking in the sense that some things that worked without it would no longer
work with it. That doesn't match the current scenario at all.
In terms of other threads giving reasons why no new modes were likely to be
introduced, most that I could find appeared to fail in the sense of the content
they provided, installing rules that were better found in a linter, as opposed
to a parsing mode. Do you have any points on why the idea itself is unlikely to
be implemented as opposed to the content?
I also feel that it is *impossible* for vendors to add such changes to make
error messages more useful because in the JavaScript syntax specified ten years
ago "await" didn't exist and it would just be an unexpected string. We would
have to add some new detection feature for this newer flavour to allow better
messages.
But error messages were the lowest suggestion for this new functionality, and
probably another bad example. Just consider the hundreds of previously rejected
proposals that were very promising but couldn't be used because of breaking
backwards compatability.
On 23/07/2017 05:50:31, Jordan Harband mailto:ljh...@gmail.com]> wrote:
Strict mode wasn't a breaking change; browsers that don't understand strict
mode simply ignore the no-op string.
There's lots of other threads on why no new modes are likely to ever be
introduced.
There's also no need to add pragmas or make breaking changes to make error
messages more useful; for that, I suggest filing specific suggestions on each
engine vendor's bug tracker.
On Sat, Jul 22, 2017 at 9:30 PM, Alexander Craggs mailto:alexan...@debenclipper.com]> wrote:
One of the main issues I've found with why a significant number of proposals
are rejected is because it would introduce breaking changes into JavaScript, a
language created over 22 years ago. It doesn't surprise me that people have
suggestions to improve JavaScript that are breaking, popular syntax seems to
have changed significantly in those years.
We *did* introduce some breaking changes though, using the "use strict" header
at the top of files. Would it not make sense to introduce new breaking changes
under a similar header for each change we suggest? For example, "use es7" could
allow people to say they are using the latest features.
Say we create such versioning, it would allow us to improve the language so
much more than we're currently able to, we'd no longer have to stick with
useless error messages for forgetting `async`:
```js
< function u() { let x = await "hi" }
> Uncaught SyntaxError: Unexpected string
// Now...
< "use es7";
< function u() { let x = await "hi" }
> Uncaught SomeError: "await" keyword used outside of async function
```
___
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: JavaScript Versioning
(Apologies for the double email Jordan, I accidentally replied to just you, not
es-discuss as well. I'm new to this whole mailing list thing.)
Apologies, that was a bad example. I was more considering "use strict" to be
breaking in the sense that some things that worked without it would no longer
work with it. That doesn't match the current scenario at all.
In terms of other threads giving reasons why no new modes were likely to be
introduced, most that I could find appeared to fail in the sense of the content
they provided, installing rules that were better found in a linter, as opposed
to a parsing mode. Do you have any points on why the idea itself is unlikely
to be implemented as opposed to the content?
I also feel that it is *impossible* for vendors to add such changes to make
error messages more useful because in the JavaScript syntax specified ten years
ago "await" didn't exist and it would just be an unexpected string. We would
have to add some new detection feature for this newer flavour to allow better
messages.
But error messages were the lowest suggestion for this new functionality, and
probably another bad example. Just consider the hundreds of previously
rejected proposals that were very promising but couldn't be used because of
breaking backwards compatability.
On 23/07/2017 05:50:31, Jordan Harband wrote:
Strict mode wasn't a breaking change; browsers that don't understand strict
mode simply ignore the no-op string.
There's lots of other threads on why no new modes are likely to ever be
introduced.
There's also no need to add pragmas or make breaking changes to make error
messages more useful; for that, I suggest filing specific suggestions on each
engine vendor's bug tracker.
On Sat, Jul 22, 2017 at 9:30 PM, Alexander Craggs mailto:alexan...@debenclipper.com]> wrote:
One of the main issues I've found with why a significant number of proposals
are rejected is because it would introduce breaking changes into JavaScript, a
language created over 22 years ago. It doesn't surprise me that people have
suggestions to improve JavaScript that are breaking, popular syntax seems to
have changed significantly in those years.
We *did* introduce some breaking changes though, using the "use strict" header
at the top of files. Would it not make sense to introduce new breaking changes
under a similar header for each change we suggest? For example, "use es7"
could allow people to say they are using the latest features.
Say we create such versioning, it would allow us to improve the language so
much more than we're currently able to, we'd no longer have to stick with
useless error messages for forgetting `async`:
```js
< function u() { let x = await "hi" }
> Uncaught SyntaxError: Unexpected string
// Now...
< "use es7";
< function u() { let x = await "hi" }
> Uncaught SomeError: "await" keyword used outside of async function
```
___
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
JavaScript Versioning
One of the main issues I've found with why a significant number of proposals
are rejected is because it would introduce breaking changes into JavaScript, a
language created over 22 years ago. It doesn't surprise me that people have
suggestions to improve JavaScript that are breaking, popular syntax seems to
have changed significantly in those years.
We *did* introduce some breaking changes though, using the "use strict" header
at the top of files. Would it not make sense to introduce new breaking changes
under a similar header for each change we suggest? For example, "use es7"
could allow people to say they are using the latest features.
Say we create such versioning, it would allow us to improve the language so
much more than we're currently able to, we'd no longer have to stick with
useless error messages for forgetting `async`:
```js
< function u() { let x = await "hi" }
> Uncaught SyntaxError: Unexpected string
// Now...
< "use es7";
< function u() { let x = await "hi" }
> Uncaught SomeError: "await" keyword used outside of async function
```___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Add an easier method for slicing and stepping strings and arrays
I always found the Python methodology of selecting characters from strings (or items from arrays) to be the most natural I've found among a number of language solutions. Was considering whether adding the syntax would be beneficial for JavaScript. For those who do not know, the syntax is as so: ```js const str = 'example' const arr = ['e', 'x', 'a', 'm', 'p', 'l', 'e'] // Single elements are selected as in JS: str[1] // 'x' arr[2] // 'a' // Multiple elements are selected by providing two numbers, delimited by a colon // The first number is inclusive, the last number is exclusive str[1:3] // 'xa' arr[3:6] // ['m', 'p', 'l'] // These numbers can also be negative, resulting in indexing from the end of the string/array str[-1] // 'e' str[-3:-1] // 'pl' arr[-5:-3] // ['a', 'm'] arr[0:-5] // ['e', 'x'] // There is also a third number, which steps through the selection chosen by the first two str[0:5:2] // 'eap' // This number can be negative, which results in stepping backwards through the string/array str[::-1] // 'elpmaxe' // An empty item represents one of the following based upon it's position: [0:length:1] ``` The most official documentation I could find on this topic is from the Python tutorial [https://docs.python.org/3.6/tutorial/introduction.html#strings], a more useful reference however might be the Stack Overflow post on the topic [https://stackoverflow.com/questions/509211/explain-slice-notation].___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
