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

[Michael J. Ryan]

With the promise.all, would each item in the iterable be an async function
(or function returning a promise)?  I mean, I'm presuming the point is to
not have every item execute at the same time.

-- 

Michael J. Ryan
Website: https://www.tracker1.info/
Email: track...@gmail.com
Mobile: 480-270-4509


On Fri, Sep 6, 2019 at 12:04 PM Cyril Auburtin 
wrote:

> It could be probably added as a `Promise.all(iterable, concurrency?)`
>
> Some existing implementations:
> - http://bluebirdjs.com/docs/api/promise.map.html
> - https://caolan.github.io/async/v3/docs.html#mapLimit
> - I tried to write one:
> https://github.com/caub/misc/blob/master/utils/promise-concurrent.js
>
> On Fri, Sep 6, 2019 at 8:33 PM Tom Boutell  wrote:
>
>> I am more interested in syntax two than syntax one, which I felt should
>> probably be included for completeness. But hey, as you say, maybe not since
>> unguarded concurrency is indeed usually a mistake.
>>
>> Taken on its own, do you have an objection to `for (item of items
>> concurrency 5) { ... }`?
>>
>>
>> On Fri, Sep 6, 2019 at 1:46 PM C. Scott Ananian 
>> wrote:
>>
>>> The current way to write what you want is:
>>>
>>> await Promise.all(itemsCursor.map(item => db.insert(item));
>>>
>>> or
>>>
>>> await Promise.all(itemsCursor.map(Promise.guard(5, item =>
>>> db.insert(item;
>>>
>>> if you are using a library like `prfun` (
>>> https://github.com/cscott/prfun#promiseguardfunctionnumber-condition-function-fn--function
>>> ).
>>>
>>> I'm not sure adding a new parallel loop construct is an obvious
>>> improvement on this, especially since unguarded concurrent execution is
>>> usually a mistake (can cause memory requirements to blow up), as you point
>>> out yourself.
>>>
>>> I'd be more in favor of new syntax if it was integrated with a
>>> work-stealing mechanism, since (a) that can't as easily be done in a
>>> library function (you need access to the entire set of runnable tasks, not
>>> just the ones created in this loop), and (b) is more likely to be
>>> correct/fast by default and not lead to subtle resource-exhaustion problems.
>>>   --scott
>>>
>>> On Fri, Sep 6, 2019 at 12:40 PM Tom Boutell 
>>> wrote:
>>>
>>>> *Specifying concurrency for "for...of" loops potentially containing
>>>> "await" statements in the loop body*
>>>>
>>>> In the async/await era, I see most developers using the async and await
>>>> keywords in 90% of situations, shifting to "Promise.all" or the bluebird
>>>> library only to cope with concurrency issues.
>>>>
>>>> The most common case in my experience is the need to admit a manageable
>>>> level of parallelism when iterating a large array (or iterator, see the
>>>> final section) and performing asynchronous work on each item. Unlimited
>>>> concurrency (Promise.all) tends to overwhelm backends involved in a way
>>>> that confuses developers as to what is happening. Bluebird's "Promise.map"
>>>> permits concurrency to be specified, which is great, but requires pulling
>>>> in a library and switching of mental gears ("OK right, these async
>>>> functions return promises," etc).
>>>>
>>>> To build on the friendliness of async/await, I propose these two
>>>> syntaxes be accepted:
>>>>
>>>> SYNTAX ONE
>>>>
>>>> ```js
>>>> for (item of items concurrent) {
>>>>   // db.insert is an async function
>>>>   await db.insert(item);
>>>> }
>>>> ```
>>>>
>>>> In Syntax One, all loop bodies commence concurrently (see below for the
>>>> definition of "concurrently" with regard to async). If an exception is not
>>>> caught inside the loop, it is thrown beyond the loop, and all exceptions
>>>> subsequently thrown by concurrently executing loop bodies are discarded
>>>> (like Promise.all).
>>>>
>>>> *While I feel that unlimited concurrency is usually a mistake in a
>>>> situation where you have an array of items of unpredictable number, it
>>>> seems odd not to have a syntax for this case, and "concurrency 0" seems
>>>> clunky.*
>>>>
>>>> SYNTAX TWO
>>>>
>>>> ```js
>>>> for (item of items concurrency 5) {
>>>>   // db.insert is an asy

export with get/set option

[Michael J. Ryan]

I mentioned something similar to this before, but wanted to update with
some more thoughts on why it could be useful...  In my specific case, I
have the following scenario...

I have a "base" script that loads build values into window.__BASE__, the
application in question is deployed on multiple clients, so strings and
other configuration values are different.  The configuration project is
built separately and the correct configuration is built with CI/CD.  There
are other configuration options that are loaded via the API that are client
configurable.  I know it's a bit different of a use case, but it can't be
*that* unique.  I also understand that it's a minefield of mutation, but
it's pretty centrally controlled early, and simplifies a *LOT* of the rest
of the application.

For example, I currently have the following in my "base.js" reference
inside my project...

// --- BEGIN JS
const base = window.__BASE__ || {}; // config from release

export const environment = base.environment || 'internal.dev';
export const api = base.api || 'https://api.app.dev-domain';
// ... other constants exported from base with defaults 

// value loaded from API before the SPA UI takes over from a spinner
export let petitionOptions = null;
export const setPetitionOptions = options => {
// client manipulation/integration here
petitionOptions = options;
};
// --- END JS

It would be nice imho if I could do the following...


// --- BEGIN JS
let _petitionOptions;
export { // no identification here, nested in object
get petitionOptions() {...},
set petitionOptions(value) {...}
};

// alternately
export get petitionOptions() {...}
export set petitionOptions(value) {...}
// --- END JS

Even more, would be the ability to do other exports via export { name:value
} in an object.  While the former method does work, I just think having a
getter/setter interface would be an interesting flexibility...  Not sure
how difficult a change it would be to making import variables assignable
and allowing the set transparently.

thoughts?

-- 
Michael J. Ryan
480-270-4509
https://www.tracker1.info/
m...@tracker1.info
track...@gmail.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Has there ever been discussion around a python-like "with" syntax?

[Michael J. Ryan]

I was going to mention C#'s using statement as well... though I do like the
use of a symbol over Ron's proposal, I think using might be a better
approach.

-- 
Michael J. Ryan
480-270-4509
https://www.tracker1.info/
m...@tracker1.info
track...@gmail.com


On Mon, Oct 15, 2018 at 11:50 AM Till Schneidereit <
t...@tillschneidereit.net> wrote:

> Ron Buckton has a proposal that's quite similar to what you're talking
> about: https://github.com/tc39/proposal-using-statement
>
> On Mon, Oct 15, 2018 at 11:40 AM Dan Aprahamian 
> wrote:
>
>> Hello all! First time posting here. I was curious if there was ever talk
>> about adding something similar to python's with syntax to JS. Obviously we
>> already have a "with" keyword, but I figure we could probably use "use" as
>> the keyword instead. I was thinking something like
>>
>> // Some user defined resource that can be "entered" and "exited"
>> class MyResource {
>>   // Function called when entered
>>   async [Symbol.enter]() {
>>   }
>>
>>   // Function called when exited
>>   [Symbol.exit]() {
>>   }
>> }
>>
>> const resource = new MyResource();
>>
>> async function useResource() {
>>   use myResource {
>> // Inside here, resource has had "acquire" called on it
>>
>> await doSomethingAsync();
>> // Once this block is finished executing (including async)
>> // release is called
>>   }
>>   // Release has been called now
>> }
>>
>> Use would effectively be the equivalent of:
>>
>> async function use(resource, body) {
>>   await resource[Symbol.enter]();
>>   try {
>> await body();
>>   } finally {
>> await resource[Symbol.exit]();
>>   }
>> }
>>
>> Has something like this been considered before?
>>
>> Thanks,
>> Dan
>> ___
>> 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: javascript vision thing

[Michael J. Ryan]

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  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
>
> ___
> 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

ESM exporting getters and setters.

[Michael J. Ryan]

// myFoo.mjs
_hiddenFoo = false;
export get foo() {
  return _hiddenFoo;
}

export set foo(value) {
  _hiddenFoo = !!value;
}

// main.mjs
import {foo} from './myFoo.mjs';

Not sure if this has been discussed, but would be a nice feature to have in
some cases... I know, total side effects and mutations, all the same, would
be a nice to have in a few cases.

-- 
Michael J. Ryan
480-270-4509
https://www.tracker1.info/
m...@tracker1.info
track...@gmail.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JSON support for BigInt in Chrome/V8

[Michael J. Ryan]

Out of bounds as you'd still have to parse it, but for encoding, could add
BigInt.prototype.toJSON ...

On Tue, Jul 17, 2018, 15:44 Andrea Giammarchi 
wrote:

> I guess a better example would've been `Boolean('false')` returns true,
> but yeah, I've moved slightly forward already with everything, if you read
> other messages.
>
> Regards.
>
> On Wed, Jul 18, 2018 at 12:06 AM Waldemar Horwat 
> wrote:
>
>> On 07/17/2018 04:27 AM, Andrea Giammarchi wrote:
>> > actually, never mind ... but I find it hilarious
>> that BigInt('55501') works
>> but BigInt('55501n') doesn't ^_^;;
>>
>> That's no different from how other built-in types work.  String('"foo"')
>> doesn't give you the same string as the string literal "foo".
>>
>>  Waldemar
>>
> ___
> 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: Adding support for enums

[Michael J. Ryan]

Just use symbols for your action type

On Sat, Jun 9, 2018, 14:21 Doug Wade  wrote:

> Hello friends!
>
> I had a bug the other day on my team.  We use redux  to
> manage the state on our application , which
> is maintained by a large team.  In Redux, there are actions, which are
> strings, that get passed to a reducer, which mutates the states.  My
> coworker and I inadvertently added the same action name, "LOADING" on the
> same page, but in two different files.  This led to a bug when both my
> modal and his search results would be loading at the same time, but since
> they were never both visible, we didn't catch the bug.  My coworker
> refactored his feature, and broke my feature, such that rather than
> displaying a spinner, we went straight to an empty results page, even when
> there were results.
>
> In other languages, like the language I use most at work, Java, we would
> instead use a language construct called an enum
>  in this situation so that
> the two different sets of actions weren't equal to each other.  I did some
> research into some previous discussions on this
>  topic, and it seems like the
> discussion has been broadly in favor of it. I also noted that enum is a 
> reserved
> keyword
> ,
> which indicates some intention to add enums to the language.
>
> As such, I've spent some time working on a proposal
>  for adding enums
> to ECMAScript. It is very heavily based on the work by rauschma
> , stevekinney
>  and rwaldron
> . I wasn't sure if
> I was using all the right words when writing the proposal, so to help
> express myself better, I also spent some time writing a babel plugin
>  that
> uses a polyfill  against
> which I've written a small test suite
>  (if you would like to run
> them, you'll need to link the polyfill and the babel plugin into the
> tests). Please do not take these as any indication of "done-ness", I wrote
> them to understand how I would expect an enum in javascript to behave, and
> am willing and eager to make changes as I get suggestions. I do, however,
> feel I have done as much as I can on my own, and would like help in
> considering the proposal, especially whether it contains any footguns,
> undefined behavior, or things that would be surprising to newer developers,
> and helping me identify what work is to be done to make this a "real"
> proposal.
>
> All the best,
> Doug Wade
>
> ___
> 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: Suggestion: Add Standard IO Streams

[Michael J. Ryan]

Why not create an npm module that represents what you'd like to see as an
interface wrapping node's implementation and propose your new interface?

This way you can try building something with it.  You'll first need to
implement how you see a synchronous stream in the first place.

Streams can be a complex beast though.  Do you want a synchronous or
asynchronous implementation or both?  Will they consume like generators,
async iteration (for await of)?  What about queueing and back pressure?

On Sat, Apr 28, 2018, 22:28 Chet Michals  wrote:

> Working between a number of different ECMAScript environments over the
> years, such as in Java with Rhino and Nashorn, Node.js, and various web
> browsers, one thing I have noticed is that there is no standard
> input/output/error stream like most other languages support, and each
> ecosystem tends to define their own host objects to deal with these, like
> the console object in most Web Browsers (Which is at least defined in a
> WHATWG Living Standard), the process object in Node.js, and the print
> object in Nashorn.
>
> I feel for long term portability, the 3 standard IO streams should be
> added to the spec in some way,
>
> Is there a reason I am not seeing as to why this wouldn't be desired?
> ___
> 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: performance benchmark of async-design-patterns - recursive-callbacks vs. promises vs. async/await

[Michael J. Ryan]

Nice... And not really surprising.  I am slightly surprised async/await is
so close to promises.  Which means that improving promises performance
should probably be a priority.  I still feel the easier to reason with code
is well worth it, given many apps now scale horizontally.

On Sun, Apr 29, 2018, 10:31 kai zhu  wrote:

> fyi, here are some benchmark results of nodejs' client-based http-request
> throughput, employing various async-design-patterns (on a 4gb linode box).
>  overall, recursive-callbacks seem to ~15% faster than both async/await and
> promises (~3000 vs ~2600 client-http-request/s).
>
> ```shell
> $ REQUESTS_PER_TICK=10 node example.js
>
> state 1 - node (v9.11.1)
> state 2 - http-server listening on port 3000
> ...
> state 3 - clientHttpRequestWithRecursiveCallback - flooding http-server
> with request "http://localhost:3000;
> state 5 - clientHttpRequestWithRecursiveCallback - testRun #99
> state 5 - clientHttpRequestWithRecursiveCallback - requestsTotal = 14690
> (in 5009 ms)
> state 5 - clientHttpRequestWithRecursiveCallback - requestsPassed = 7349
> state 5 - clientHttpRequestWithRecursiveCallback - requestsFailed = 7341 ({
> "statusCode - 500": true
> })
> state 5 - clientHttpRequestWithRecursiveCallback - 2933 requests / second
> state 5 - mean requests / second = {
> "clientHttpRequestWithRecursiveCallback": "3059 (156 sigma)",
> "clientHttpRequestWithPromise": "2615 (106 sigma)",
> "clientHttpRequestWithAsyncAwait": "2591 (71 sigma)"
> }
> ```
>
>
> you can reproduce the benchmark-results by running this
> zero-dependency/zero-config, standalone nodejs script below:
>
>
> ```js
> /*
>  * example.js
>  *
>  * this zero-dependency example will benchmark nodejs' client-based
> http-requests throughput,
>  * using recursive-callback/promise/async-await design-patterns.
>  *
>  * the program will make 100 test-runs (randomly picking a design-pattern
> per test-run),
>  * measuring client-based http-requests/seconde over a 5000 ms interval.
>  * it will save the 16 most recent test-runs for each design-pattern,
>  * and print the mean and standard deviation.
>  * any test-run with unusual errors (timeouts, econnreset, etc),
>  * will be discarded and not used in calculations
>  *
>  * the script accepts one env variable $REQUESTS_PER_TICK, which defaults
> to 10
>  * (you can try increasing it if you have a high-performance machine)
>  *
>  *
>  *
>  * example usage:
>  * $ REQUESTS_PER_TICK=10 node example.js
>  *
>  * example output:
>  *
>  * state 1 - node (v9.11.1)
>  * state 2 - http-server listening on port 3000
>  * ...
>  * state 3 - clientHttpRequestWithRecursiveCallback - flooding http-server
> with request "http://localhost:3000;
>  * state 5 - clientHttpRequestWithRecursiveCallback - testRun #99
>  * state 5 - clientHttpRequestWithRecursiveCallback - requestsTotal =
> 14690 (in 5009 ms)
>  * state 5 - clientHttpRequestWithRecursiveCallback - requestsPassed = 7349
>  * state 5 - clientHttpRequestWithRecursiveCallback - requestsFailed =
> 7341 ({
>  * "statusCode - 500": true
>  * })
>  * state 5 - clientHttpRequestWithRecursiveCallback - 2933 requests /
> second
>  * state 5 - mean requests / second = {
>  * "clientHttpRequestWithRecursiveCallback": "3059 (156 sigma)",
>  * "clientHttpRequestWithPromise": "2615 (106 sigma)",
>  * "clientHttpRequestWithAsyncAwait": "2591 (71 sigma)"
>  * }
>  *
>  * state 6 - process.exit(0)
>  */
>
> /*jslint
> bitwise: true,
> browser: true,
> maxerr: 4,
> maxlen: 100,
> node: true,
> nomen: true,
> regexp: true,
> stupid: true
> */
>
> (function () {
> 'use strict';
> var local;
> local = {};
>
> // require modules
> local.http = require('http');
> local.url = require('url');
>
> /* jslint-ignore-begin */
> local.clientHttpRequestWithAsyncAwait = async function (url, onError) {
> /*
>  * this function will make an http-request using async/await
> design-pattern
>  */
> var request, response, timerTimeout;
> try {
> response = await new Promise(function (resolve, reject) {
> // init timeout
> timerTimeout = setTimeout(function () {
> reject(new Error('timeout - 2000 ms'));
> }, 2000);
> request = local.http.request(local.url.parse(url),
> resolve);
> request.on('error', reject);
> request.end();
> });
> await new Promise(function (resolve, reject) {
> // ignore stream-data
> response.on('data', local.nop);
> if (response.statusCode >= 400) {
> reject(new Error('statusCode - ' +
> response.statusCode));
> return;
> }
> response.on('end', resolve);
> response.on('error', reject);
> });
> } catch 

Re: Re: Proposal: Conditional `catch` in Promises

[Michael J. Ryan]

Maybe approach typescript on this one... Not sure if that supports typed
errors like C# does, but would probably suit you well.

On Wed, Apr 25, 2018, 08:31 Isiah Meadows  wrote:

> I'd still prefer we wait until pattern matching [1] gets addressed first,
> then tackling this. Error types are represented about 50 different ways in
> JS, with subtyping only being one (used by the standard kind of). Node
> appends an `err.code`, and the DOM adds a similar type, just using a common
> error subclass. And in some cases where errors are planned (but exceptions
> are more convenient), you sometimes see non-errors thrown. So there needs
> to be a means of catching all of them, and `if` checks get verbose and
> noisy in a hurry.
>
> On Wed, Apr 25, 2018, 00:11 Ayush Gupta  wrote:
>
>> We could potentially provide the same functionality in `try/catch` by
>> extending the signature of `catch` to
>>
>> ```js
>> try {
>>
>> } catch(, ) {
>>
>> }
>> ```
>>
>> If `` evaluates to truthy, invoke the `catch` block,
>> otherwise don't.
>> ___
>> 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: from './foo' import './foo';

[Michael J. Ryan]

Personally I like this syntax better, but feel that changing or adding
import syntax at this point I'd a non-starter...  Not sure what others feel
about this one.

On Wed, Apr 4, 2018, 09:23 Cyril Auburtin  wrote:

> Could
> ```js
> from 'name' import something;
> ```
>
> be added to ES module grammar?
>
> which would work like the current
> ```js
> import something from 'name';
> ```
>
> The advantage is to sort more easily import, and have autocompletion of
> imported identifiers
>
> ___
> 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 ES5 environments are still in use today?

[Michael J. Ryan]

LibreJS looks like a browser extension, not a JS engine...

Aside, wow, I'm in favor of open-source, but this one is pretty out there.

-- 
Michael J. Ryan - http://tracker1.info


On Tue, Apr 3, 2018 at 11:11 AM Joe Eagar <joe...@gmail.com> wrote:

> LibreJS? The FSF is seriously escalating the plugin/scripting issue?
>
> Joe
>
> On Mon, Apr 2, 2018 at 4:07 PM, J Decker <d3c...@gmail.com> wrote:
>
>>
>>
>> On Mon, Apr 2, 2018 at 12:46 PM, Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>>> I guess when it comes to other projects Wikipedia Wikipedia should be
>>> enough:
>>> https://en.wikipedia.org/wiki/List_of_ECMAScript_engines
>>>
>>>
>> They're missing at least one...
>> https://www.gnu.org/software/librejs/ which looks like it is missing es6
>> features (as of aug last year anyway... still?)
>>
>>
>>> FWIW I think only Chakra, SpiderMonkey, JavaScriptCore, Nashorn,
>>> QtScript (although, not standard at all), Duktape, Moddable (R.I.P.
>>> Kinoma), Espruino, MuJS (new to me!), and JerryScript are the actively
>>> used/developed/maintained, and the list misses GJS, but I guess that's
>>> because it's based on SpiderMonkey.
>>>
>>> Purely ES5 start with IE9 on browser land, but includes IE11 too which
>>> is still quite popular.
>>>
>>> Not fully ES2015 is Chrome 49 which is the latest Chrome version
>>> supported in both Windows XP and Vista and there are still users that won't
>>> let that old/cracked OS go, regardless all security issues they have.
>>>
>>> Opera 36 is at the same state of Chrome 49, and things are pretty
>>> different on mobile too.
>>>
>>> All phones from 2015 are stuck behind older Android versions or, even
>>> worst, Samsung Internet, like it is for the Galaxy A3 case which is still a
>>> pretty good looking phone.
>>>
>>> However, Samsung Browser 4.0 is not too bad compared to IE11, as you can
>>> see in this gist:
>>>
>>> https://gist.github.com/WebReflection/1411b420574c1cc4b4f08fcf9cd960c8#gistcomment-2399378
>>>
>>> Have I answered your question ?
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Apr 2, 2018 at 9:18 PM, /#!/JoePea <j...@trusktr.io> wrote:
>>>
>>>> I'm curious to know how many pure ES% environments (with or without
>>>> non-standard features like __proto__, and without any ES6 features) are
>>>> still being used in the wild.
>>>>
>>>> Would this come down to a browser statistics lookup? I believe there
>>>> are other projects that use ES, like Rhino, Espruino, etc. Do you know of
>>>> some place to get such statistics besides for browsers?
>>>>
>>>> */#!/*JoePea
>>>>
>>>> ___
>>>> es-discuss mailing list
>>>> es-discuss@mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
> ___
> 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 ES5 environments are still in use today?

[Michael J. Ryan]

I'd add in Adobe's ExtendScript variant as well, which is stuck at ES3, and
in InDesign isn't even completely shimable (my suffering has been in
InDesign lately).

Although, most who touch Adobe ExtendScript are well aware of its'
limitations.

-- 
Michael J. Ryan - http://tracker1.info


On Mon, Apr 2, 2018 at 4:07 PM J Decker <d3c...@gmail.com> wrote:

>
>
> On Mon, Apr 2, 2018 at 12:46 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> I guess when it comes to other projects Wikipedia Wikipedia should be
>> enough:
>> https://en.wikipedia.org/wiki/List_of_ECMAScript_engines
>>
>>
> They're missing at least one...
> https://www.gnu.org/software/librejs/ which looks like it is missing es6
> features (as of aug last year anyway... still?)
>
>
>> FWIW I think only Chakra, SpiderMonkey, JavaScriptCore, Nashorn, QtScript
>> (although, not standard at all), Duktape, Moddable (R.I.P. Kinoma),
>> Espruino, MuJS (new to me!), and JerryScript are the actively
>> used/developed/maintained, and the list misses GJS, but I guess that's
>> because it's based on SpiderMonkey.
>>
>> Purely ES5 start with IE9 on browser land, but includes IE11 too which is
>> still quite popular.
>>
>> Not fully ES2015 is Chrome 49 which is the latest Chrome version
>> supported in both Windows XP and Vista and there are still users that won't
>> let that old/cracked OS go, regardless all security issues they have.
>>
>> Opera 36 is at the same state of Chrome 49, and things are pretty
>> different on mobile too.
>>
>> All phones from 2015 are stuck behind older Android versions or, even
>> worst, Samsung Internet, like it is for the Galaxy A3 case which is still a
>> pretty good looking phone.
>>
>> However, Samsung Browser 4.0 is not too bad compared to IE11, as you can
>> see in this gist:
>>
>> https://gist.github.com/WebReflection/1411b420574c1cc4b4f08fcf9cd960c8#gistcomment-2399378
>>
>> Have I answered your question ?
>>
>>
>>
>>
>>
>> On Mon, Apr 2, 2018 at 9:18 PM, /#!/JoePea <j...@trusktr.io> wrote:
>>
>>> I'm curious to know how many pure ES% environments (with or without
>>> non-standard features like __proto__, and without any ES6 features) are
>>> still being used in the wild.
>>>
>>> Would this come down to a browser statistics lookup? I believe there are
>>> other projects that use ES, like Rhino, Espruino, etc. Do you know of some
>>> place to get such statistics besides for browsers?
>>>
>>> */#!/*JoePea
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allow arrow functions with conventional 'function' declarations

[Michael J. Ryan]

While I appreciate your sentiment, and often relied on housing myself.
These days I'd be inclined to continue with the classic funny definition
and hosting, or more likely to break it into a separate, testable module.

Not to be contain.

On Thu, Mar 29, 2018, 02:31 Michael Luder-Rosefield 
wrote:

> You're probably asking what on Earth the point of this is, and I'll tell
> you: _hoisting_.
>
> My preferred ES5 code style was always to declare functions after their
> use:
>
> ```
> doSomething1();
> doSomething2();
>
> function doSomething1 () {
>   // ...
> }
>
> function doSomething2 () {
>   // ...
> }
>
> It keeps things uncluttered and readable: you don't have to read through
> random functions before they are used, and have to work out what they're
> doing there.
>
> If you're able to make use of ES6 arrow functions declared with
> `const`/`let`, though, you would have to declare them before use. This
> obviously goes against my preferred style, and can also result in
> inconsistent placing of function declarations when mixed with conventional
> functions.
>
> My proposal is simple: after the initial `function name (params)`, allow
> the following forms:
> 1. { // body code }
> 2. => { // body code }
> 3. => // expression ;
>
> 1. is of course the current form
> 2. is similar, except it's a block body arrow function (all the usual
> arrow function differences apply; this binding, cannot be used with 'new',
> no 'arguments', no 'super'...)
> 3. allows for concise body arrow functions - semi-colon at end.
>
> Example:
>
> ```
> // with proposal
> doSomething1();
> doSomething2()
>   .then(doSomething3);
>
> function doSomething1 () {
>  // conventional function
> }
>
> function doSomething2 () => {
>  // block body arrow function
> }
>
> function doSomething3 (value) => value ? foo(value) : bar();
>
> // without proposal
> const doSomething2 = () => {
>   // block body arrow function
>   };
> doSomething3 = value => value ? foo(value) : bar();
>
> doSomething1();
> doSomething2()
>   .then(doSomething3);
>
> function doSomething1 () {
>  // conventional function
> }
> ```
> As you can see, the latter code is just... messy and unpleasant.
>
> I don't think there's any potential issues in regards to interpreting
> syntax (it just requires a simple check for an arrow after the parameters),
> nor with readability. Async We would definitely need to clarify behaviour
> with `async` and generator functions, though.
> ___
> 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.repeat

[Michael J. Ryan]

Or for that matter, similarly  Array.fill(), which has the same
signature, but an empty array as Array.prototype.fill.

-- 
Michael J. Ryan - http://tracker1.info


On Tue, Mar 27, 2018 at 5:24 PM Michael J. Ryan <track...@gmail.com> wrote:

> How about something like...
>
> Array.prototype.fill = function(filler, times, flatten) {
>   var ret = [].concat(this);
>   var len = Number(times) || 0;
>   var (var i=0; i<len; i++) {
> if (flatten && Array.isArray(filler)) {
>   ret.push.apply(ret, filler);
> } else {
>   ret.push(filler);
> }
>   }
>   return ret;
> }
>
> [].fill(0, 3) // [0, 0, 0]
> [].fill(['a', 'b'], 2) // [['a', 'b'], ['a', 'b']]
> [].fill(['a', 'b'], 2, true) // ['a', 'b', 'a', 'b']
>
> --
> Michael J. Ryan - http://tracker1.info
>
>
> On Mon, Mar 26, 2018 at 12:02 PM Cyril Auburtin <cyril.aubur...@gmail.com>
> wrote:
>
>> > maybe fill with incrementing number?
>>
>> ```js
>> Array.from({length: 6}, (_, i) => i)
>> ```
>>
>> > Are there use cases for filling with alternating values, as in `['x',
>> 'y'].repeat(3)`?
>>
>> Not so many, but for example when working with flat matrices,
>> `[0,0,255,1].repeat(len)` for generating quickly a uniform imageData
>>
>> But even with one item, I find `[x].repeat(n)` more explicit than the 2
>> other alternatiives
>>
>> It's somewhat close to array comprehensions (that I don't really miss
>> though)
>>
>>
>> 2018-03-26 15:27 GMT+02:00 Jerry Schulteis <jdschult...@yahoo.com>:
>>
>>> Whatever the use cases might be, I like generators and spread for
>>> filling an array with values, e.g.:
>>>
>>> ```js
>>> function* repeat(n, ...values) {
>>>   for (let i = 0; i < n; ++i) {
>>> yield* values;
>>>   }
>>> }
>>>
>>> [...repeat(3, 'x', 'y')]
>>> ```
>>>
>>>
>>> On Sunday, March 25, 2018, 3:41:10 PM CDT, Claude Pache <
>>> claude.pa...@gmail.com> wrote:
>>>
>>>
>>> [...]
>>>
>>> For filling a new array with one value, `Array(n).fill('foo')` seems
>>> reasonable to me.
>>>
>>> Are there use cases for filling with alternating values, as in `['x',
>>> 'y'].repeat(3)`?
>>>
>>>
>> ___
>> 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.repeat

[Michael J. Ryan]

How about something like...

Array.prototype.fill = function(filler, times, flatten) {
  var ret = [].concat(this);
  var len = Number(times) || 0;
  var (var i=0; i<len; i++) {
if (flatten && Array.isArray(filler)) {
  ret.push.apply(ret, filler);
} else {
  ret.push(filler);
}
  }
  return ret;
}

[].fill(0, 3) // [0, 0, 0]
[].fill(['a', 'b'], 2) // [['a', 'b'], ['a', 'b']]
[].fill(['a', 'b'], 2, true) // ['a', 'b', 'a', 'b']

-- 
Michael J. Ryan - http://tracker1.info


On Mon, Mar 26, 2018 at 12:02 PM Cyril Auburtin <cyril.aubur...@gmail.com>
wrote:

> > maybe fill with incrementing number?
>
> ```js
> Array.from({length: 6}, (_, i) => i)
> ```
>
> > Are there use cases for filling with alternating values, as in `['x',
> 'y'].repeat(3)`?
>
> Not so many, but for example when working with flat matrices,
> `[0,0,255,1].repeat(len)` for generating quickly a uniform imageData
>
> But even with one item, I find `[x].repeat(n)` more explicit than the 2
> other alternatiives
>
> It's somewhat close to array comprehensions (that I don't really miss
> though)
>
>
> 2018-03-26 15:27 GMT+02:00 Jerry Schulteis <jdschult...@yahoo.com>:
>
>> Whatever the use cases might be, I like generators and spread for filling
>> an array with values, e.g.:
>>
>> ```js
>> function* repeat(n, ...values) {
>>   for (let i = 0; i < n; ++i) {
>> yield* values;
>>   }
>> }
>>
>> [...repeat(3, 'x', 'y')]
>> ```
>>
>>
>> On Sunday, March 25, 2018, 3:41:10 PM CDT, Claude Pache <
>> claude.pa...@gmail.com> wrote:
>>
>>
>> [...]
>>
>> For filling a new array with one value, `Array(n).fill('foo')` seems
>> reasonable to me.
>>
>> Are there use cases for filling with alternating values, as in `['x',
>> 'y'].repeat(3)`?
>>
>>
> ___
> 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: partial spread syntax

[Michael J. Ryan]

I'm not sure I'd prefer this over just using a function on the Array
prototype... you aren't saving too many characters and are adding some
ambiguity with regards to {} usage.  I don't like it.

-- 
Michael J. Ryan - http://tracker1.info


On Mon, Mar 26, 2018 at 5:25 AM Mike Samuel <mikesam...@gmail.com> wrote:

>
>
> On Sun, Mar 25, 2018 at 9:20 PM, 月の影 <19511...@qq.com> wrote:
>
>> Sometimes I got a infinity iterable sequences, I may want a partial
>> spreed syntax. `...iterableObject{from, to}`
>>
>
> How would you prevent ambiguity between the spread and blocks?
>
> iterable
> {
>   from, to
> };
>
> is currently equivalent to
>
> iterable;
> {
>   from, to;
> }
>
>
> ___
> 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 additions

[Michael J. Ryan]

Agreed, decent additions... also bonus for being shimmable (no new syntax).

-- 
Michael J. Ryan - http://tracker1.info


On Sun, Mar 25, 2018 at 11:49 PM Isiah Meadows <isiahmead...@gmail.com>
wrote:

> I have a few (typed) array additions I'd like to see added, detailed
> in this repo. By any chance, how many of these do you all see worth
> adding, if any?
>
> https://github.com/isiahmeadows/array-additions-proposal/
>
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> 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: Re: Function composition vs pipeline

[Michael J. Ryan]

Nobody is wishing away anything with a linter.  The linter can only enforce
a choice not to use a given language feature.

In any case, I feel this syntax is very valuable, fairly obvious in use,
and similar to use in other languages.

 Pipeline/composition are important features, touched on by several user
libraries, none of which are as clean or obvious as the syntax additions
proposed.

On Wed, Mar 21, 2018, 01:53 Terence M. Bandoian  wrote:

> That's very true.  However, every new feature is an added cost to the
> developer that can't be wished away with a linter.
>
> -Terence Bandoian
>
>
> On 3/20/2018 6:07 PM, Jordan Harband wrote:
>
> Learning is a continuing requirement with or without new features in the
> language; any one feature *not* added to the language tends to mean you'll
> have to learn about more than one userland solution to that problem.
> Obviously there's a cost to adding anything to the language - but there's a
> cost to *not* adding things too - and in no case are you afforded the
> luxury of "no more learning".
>
> On Tue, Mar 20, 2018 at 12:23 PM, Terence M. Bandoian 
> wrote:
>
>> When "features" are added to the language, developers have to learn
>> them.  Either that or risk being relegated to second class status.  That
>> means more time learning about and testing and sorting out support for new
>> features and less time actually developing an application.  I like the idea
>> of "keeping it small".  To me, the ideal is a balance of simple and
>> powerful.
>>
>> -Terence Bandoian
>>
>>
>>
>> On 3/13/2018 9:59 AM, Mark Miller wrote:
>>
>>
>>
>> On Mon, Mar 12, 2018 at 11:33 PM, Jordan Harband 
>> wrote:
>>
>>> As someone who does wear the shoes of a senior programmer responsible
>>> (along with my team) for overseeing a very very large web project, the
>>> super trivial and easy answer to this is "use a linter" - eslint can be
>>> configured to restrict any syntax you like, and since surely your CI
>>> process is already gating any merges, so too can the linter be used to gate
>>> merges, which will prevent anyone from any using any syntax you deem
>>> unclean.
>>>
>>> Tons of new syntax can be added to JavaScript forever and it need not
>>> have a single bit of impact on any of your project's code except a few
>>> lines in your eslint configuration.
>>>
>>
>>
>> Hi Jordan, while I agree with some of your overall point, I think this
>> goes way too far. The larger the language, and the more diversity there is
>> in which subset one shop chooses vs another, the more we loose the benefits
>> of having many developers use a common language. No one shop writes all the
>> JS they use. They use libraries written by others whose lint rules are
>> different. They hire programmers from other shops. They read and post to
>> stackOverflow, etc.
>>
>> Much better is for the language to omit as much as possible, keeping it
>> small. I am glad my "Tragedy of the Common Lisp" post is so widely cited
>> and appreciated. Later in that thread, at
>> https://esdiscuss.org/topic/the-tragedy-of-the-common-lisp-or-why-large-languages-explode-was-revive-let-blocks#content-22
>> I state a hierarchy of different parts of a language with different
>> pressures towards minimality:
>>
>>
>> the force of my [minimality] point gets weaker as we move from core
>>> language to standardizing libraries. The overall standard language can be
>>> seen as consisting of these major parts:
>>>
>>>- fundamental syntax -- the special forms that cannot faithfully be
>>>explained by local expansion to other syntax
>>>
>>>
>>>- semantic state -- the state than computation manipulates
>>>
>>>
>>>- kernel builtins -- built in library providing functionality that,
>>>if it were absent, could not be provided instead by user code.
>>>
>>>
>>>- intrinsics -- libraries that semantic state or kernel builtins
>>>depend on. For example, with Proxies, one might be able to do Array in 
>>> user
>>>code. But other kernel builtins already have a dependency on Array
>>>specifically, giving it a privileged position over any replacement.
>>>
>>>
>>>- syntactic sugar -- the syntax that can be explained by local
>>>expansion to fundamental syntax.
>>>
>>>
>>>- global convenience libraries -- could be implemented by
>>>unprivileged user code, but given standard global naming paths in the
>>>primordial global namespace.
>>>
>>>
>>>- standard convenient library modules
>>>
>>> I have listed these in order, according to my sense of the costs of
>>> growth and the urgency for minimalism. For all of these we still need to
>>> exercise discipline. But it is only for the last one that we should
>>> consider growth of absolute size to be unbounded; restricting ourselves
>>> only to the rate of growth as we wait for candidates to prove themselves
>>> first by the de facto process. Ideally, TC39 should stop being the
>>> bottleneck on 

Re: JSON.canonicalize()

[Michael J. Ryan]

JSON is utf-8 ... As far as 16 but coffee points, there are still astral
character pairs.  Binary data should be enclosed to avoid this, such as
with base-64.

On Fri, Mar 16, 2018, 09:23 Mike Samuel  wrote:

>
>
> On Fri, Mar 16, 2018 at 11:38 AM, C. Scott Ananian 
> wrote:
>
>> Canonical JSON is often used to imply a security property: two JSON blobs
>> with identical contents are expected to have identical canonical JSON forms
>> (and thus identical hashed values).
>>
>
> What does "identical contents" mean in the context of numbers?  JSON
> intentionally avoids specifying any precision for numbers.
>
> JSON.stringify(1/3) === '0.'
>
> What would happen with JSON from systems that allow higher precision?
> I.e., what would (JSON.canonicalize(JSON.stringify(1/3) + '3')) produce?
>
>
>
>
>
>> However, unicode normalization allows multiple representations of "the
>> same" string, which defeats this security property.  Depending on your
>> implementation language
>>
>
> We shouldn't normalize unicode in strings that contain packed binary
> data.  JSON strings are strings of UTF-16 code-units, not Unicode scalar
> values and any system that assumes the latter will break often.
>
>
>> and use, a string with precomposed accepts could compare equal to a
>> string with separated accents, even though the canonical JSON or hash
>> differed.  In an extreme case (with a weak hash function, say MD5), this
>> can be used to break security by re-encoding all strings in multiple
>> variants until a collision is found.  This is just a slight variant on the
>> fact that JSON allows multiple ways to encode a character using escape
>> sequences.  You've already taken the trouble to disambiguate this case;
>> security-conscious applications should take care to perform unicode
>> normalization as well, for the same reason.
>>
>> Similarly, if you don't offer a verifier to ensure that the input is in
>> "canonical JSON" format, then an attacker can try to create collisions by
>> violating the rules of canonical JSON format, whether by using different
>> escape sequences, adding whitespace, etc.  This can be used to make JSON
>> which is "the same" appear "different", violating the intent of the
>> canonicalization.  Any security application of canonical JSON will require
>> a strict mode for JSON.parse() as well as a strict mode for
>> JSON.stringify().
>>
>
> Given the dodginess of "identical" w.r.t. non-integral numbers, shouldn't
> endpoints be re-canonicalizing before hashing anyway?  Why would one want
> to ship the canonical form over the wire if it loses precision?
>
>
>
>>   --scott
>>
>> On Fri, Mar 16, 2018 at 4:48 AM, Anders Rundgren <
>> anders.rundgren@gmail.com> wrote:
>>
>>> On 2018-03-16 08:52, C. Scott Ananian wrote:
>>>
 See http://wiki.laptop.org/go/Canonical_JSON -- you should probably at
 least
 mention unicode normalization of strings.

>>>
>>> Yes, I could add that unicode normalization of strings is out of scope
>>> for this specification.
>>>
>>>
>>> You probably should also specify a validator: it doesn't matter if you
 emit canonical JSON if you can tweak the hash of the value by feeding
 non-canonical JSON as an input.

>>>
>>> Pardon me, but I don't understand what you are writing here.
>>>
>>> Hash functions only "raison d'être" are providing collision safe
>>> checksums.
>>>
>>> thanx,
>>> Anders
>>>
>>>
>>>--scott

 On Fri, Mar 16, 2018 at 3:16 AM, Anders Rundgren <
 anders.rundgren@gmail.com >
 wrote:

 Dear List,

 Here is a proposal that I would be very happy getting feedback on
 since it builds on ES but is not (at all) limited to ES.

 The request is for a complement to the ES "JSON" object called
 canonicalize() which would have identical parameters to the existing
 stringify() method.

>>>
> Why should canonicalize take a replacer?  Hasn't replacement already
> happened?
>
>
>
>> The JSON canonicalization scheme (including ES code for emulating
 it), is described in:

 https://cyberphone.github.io/doc/security/draft-rundgren-json-canonicalization-scheme.html
 <
 https://cyberphone.github.io/doc/security/draft-rundgren-json-canonicalization-scheme.html
 >

 Current workspace:
 https://github.com/cyberphone/json-canonicalization <
 https://github.com/cyberphone/json-canonicalization>

 Thanx,
 Anders Rundgren
 ___
 es-discuss mailing list
 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
>> 

Re: Pointers

[Michael J. Ryan]

Please no, mutable objects are bad enough imho.

On Mon, Mar 19, 2018, 12:47 Sebastian Malton  wrote:

> Proposal:
> Add a new variable-esk type called pointer which acts sort of like a
> reference to the data which it has been assigned to but modifies also the
> original reference when modified.
>
> Justification:
> When working with objects in particular it is often useful for satiny
> reasons to use local variables (mostly const's) as a shorthand reference
> both for compactness and also so that you don't have to type out the entire
> path every type. This would allow for non - objects but also overwriting
> objects if wanted but still have this freedom and convenience.
>
> Method:
> Add a new notation
>
> ```
> let:prt name = obj.field.name.fullname;
> ```
>
> Here if `name` is updated or if `obj.field.name.fullname` is updated so is
> the other.
>
> Sebastian Malton
> ___
> 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

Super function

[Michael J. Ryan]

What might be better is to extend break for named functions.

function someFn(arr) {
  return arr.map(e => {
if(...) {
  break someFn return "...";
}
return e * 2;
  });
}

This way you know what you're breaking from.. super would imply one level
deep.. break already has some similar constructs.  In this case it must be
a named function or named variable assigned a function.  Not a reserved
word (break while, break for, etc already works)


-- 
Michael J. Ryan - track...@gmail.com - http://tracker1.info

Please excuse grammar errors and typos, as this message was sent from my
phone.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: super return

[Michael J. Ryan]

if (arr.find(e => typeof e != 'number')) throw new Error('...');

return arr.map(e => {
  if (!...) throw new Error(...);
  return e * 2;
});

Odds are you need a conditional block, might as well be try catch.


-- 
Michael J. Ryan - track...@gmail.com - http://tracker1.info

Please excuse grammar errors and typos, as this message was sent from my
phone.

On Aug 28, 2017 1:17 PM, "Tab Atkins Jr." <jackalm...@gmail.com> wrote:

> On Mon, Aug 28, 2017 at 12:29 PM, Sebastian Malton
> <sebast...@malton.name> wrote:
> > I have seen some people want to modify some of the array prototype
> > functions, especially forEach, so that returning from them returns a
> value.
> > However, I have also seems that this could break things since in some
> cases,
> > again forEach, the return value in explicitly defined.
> >
> > Thus I propose the new syntax `super return` and any other positive
> number
> > of supers. This syntax is currently not valid in any scenario and with
> the
> > current meaning of super seems, to me at least, relativity easy to
> > understand.
> >
> > The outcome of this basically means "return from current context up one
> > level and then return from there".
> >
> > A current method of doing this is by using try / catch but it is not
> ideal.
> > Using the above method I believe that it would be able to be better
> > optimized.
>
> This has been suggested in the past, by adding a fourth argument to
> the callback signature passing an opaque "halt" value. Returning the
> halt value would end execution of the looping function prematurely.
> No reason to add new syntax for this, plus hooks for userland to take
> advantage of it, when we can just use something that userland could
> adopt *today*.
>
> (As an added bonus, it would make the callback arguments be Element,
> Index, Collection, Halt, finally spelling out Brendan's full last
> name. ^_^)
>
> ~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: super return

[Michael J. Ryan]

Well, there's already .map(), .find() and .filter() for returning values
from arrays


-- 
Michael J. Ryan - track...@gmail.com - http://tracker1.info

Please excuse grammar errors and typos, as this message was sent from my
phone.

On Aug 28, 2017 12:30 PM, "Sebastian Malton" <sebast...@malton.name> wrote:

> I have seen some people want to modify some of the array prototype
> functions, especially forEach, so that returning from them returns a value.
> However, I have also seems that this could break things since in some
> cases, again forEach, the return value in explicitly defined.
>
> Thus I propose the new syntax `super return` and any other positive number
> of supers. This syntax is currently not valid in any scenario and with the
> current meaning of super seems, to me at least, relativity easy to
> understand.
>
> The outcome of this basically means "return from current context up one
> level and then return from there".
>
> A current method of doing this is by using try / catch but it is not
> ideal. Using the above method I believe that it would be able to be better
> optimized.
>
>
> ___
> 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: Return value of forEach

[Michael J. Ryan]

Woudn't Array.prototype.all satisfy those use cases, they run until a falsy
value is returned.

-- 
Michael J. Ryan - http://tracker1.info

On Thu, Jul 6, 2017 at 6:51 AM, Naveen Chawla <naveen.c...@gmail.com> wrote:

> Suitable for that would be an "until" function that returns an array with
> all elements of the target array until a condition is met (which can then
> be followed by a chained call to forEach/forEvery), not "forEach" /
> "forEvery" as such. Reason: readability. The counterpart could be an
> "after" function which returns an array with all elements after the first
> element that satisfies a condition. (Maybe even "untilInclusive"/"from" for
> the inclusive versions too).
>
> On 6 July 2017 at 18:21, Sebastian Malton <sebast...@malton.name> wrote:
>
>> Would allowing for each to have the following two properties also help?
>>
>> 1. Returning a falsy value ends the chain and the next element will not
>> be called
>> 2. Ability to pass in a call back as parameter 4 and if present will stop
>> the next element from being iterated over until the callback is called with
>> a truthy value (falsey also ends)
>>
>>
>>
>> *From:* naveen.c...@gmail.com
>> *Sent:* July 6, 2017 8:44 AM
>> *To:* es-discuss@mozilla.org
>> *Subject:* Re: Re: Return value of forEach
>>
>> In that case, there should be a new function:
>>
>> "forEvery" (or "forEachAndReturn" or "each" or whatever)
>>
>> that does exactly the same as "forEach" but returns the array.
>>
>> This is a much needed feature for those of us that don't want to create a
>> new array on each invocation but still have the ability to transform the
>> contents of the array (or do some other processing) from within a .sort /
>> .map / .filter etc. chain.
>>
>> Otherwise, in complicated transformations, we have to end the chain,
>> perform the forEach separately, and then resume the chain, making the code
>> more messy. Sort is an example of a function that already allows mutation
>> of the existing array and returns it, so this would be nothing
>> extraordinary for ES.
>>
>
>
> ___
> 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 timezone data to Date

[Michael J. Ryan]

Cool... Have some suggestions on tweaks, but looks like a good start...
Will look through issues later and as some... At first glance, two things
stick out.

Each type should accept a single string input at least in a format that
matches the output...

I'd prefer DateTime* over *DateTime, such as DateTimeOffset ...  Mainly
that indexing in documentation, and Autocomplete will be more
discoverable.  Even if the sub-type is more intuitive in speach than
type-sub


-- 
Michael J. Ryan - track...@gmail.com - http://tracker1.info

Please excuse grammar errors and typos, as this message was sent from my
phone.

On Jun 20, 2017 4:18 PM, "Maggie Pint" <maggiep...@gmail.com> wrote:

> I have this work well underway.
>
> See https://github.com/maggiepint/proposal-temporal
>
> I am very happy to receive community feedback on this matter, so let me
> know what you think. I do expect we'll be pushing some updates to the mock
> API in the next week or so.
>
> On Tue, Jun 20, 2017 at 4:15 PM, Michael J. Ryan <track...@gmail.com>
> wrote:
>
>> Looking at moment-timezone the biggest issue is actually the timezone
>> data.
>>
>> I'm thinking that if there were a standard representation for browsers
>> and node to make this available it would be a good thing.
>>
>> I'm suggesting this as a step towards getting moment and/or another
>> better date library into js.  Since even with a library the amount of tz
>> data is pretty large and every increasing.
>>
>> Also, normalizing the zones and current offset and support for dst is a
>> big plus imho.  I'm pretty sure this had been discussed before, but have
>> only been liking here a year or so now.
>>
>> --
>> Michael J. Ryan - track...@gmail.com - http://tracker1.info
>>
>> Please excuse grammar errors and typos, as this message was sent from my
>> phone.
>>
>> ___
>> 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

Add timezone data to Date

[Michael J. Ryan]

Looking at moment-timezone the biggest issue is actually the timezone data.

I'm thinking that if there were a standard representation for browsers and
node to make this available it would be a good thing.

I'm suggesting this as a step towards getting moment and/or another better
date library into js.  Since even with a library the amount of tz data is
pretty large and every increasing.

Also, normalizing the zones and current offset and support for dst is a big
plus imho.  I'm pretty sure this had been discussed before, but have only
been liking here a year or so now.

-- 
Michael J. Ryan - track...@gmail.com - http://tracker1.info

Please excuse grammar errors and typos, as this message was sent from my
phone.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature request: Array.prototype.random

[Michael J. Ryan]

Just putting in my $.02

I'm thinking math-rnd-util as an npm module would be a place to start...
Then propose extending Math.rnd = rnd-util

Rnd.fill(array)
Rnd.pick(array)
Rnd.pick(min:int, max:int)
...

I suggest flushing things out in a usable npm module would be a good start.

-- 
Michael J. Ryan - track...@gmail.com - http://tracker1.info

Please excuse grammar errors and typos, as this message was sent from my
phone.

On Jun 20, 2017 3:20 AM, "Henrik Sommerland" <henrik.sommerl...@gmail.com>
wrote:

> I agree that having a random integer function would be more suitable.
> Picking a random element from an array is a fairly uncommon thing but
> generating a random integer in a given range is something much more
> desirable.
>
> 2017-06-20 11:33 GMT+02:00 Isiah Meadows <isiahmead...@gmail.com>:
>
>> Better idea: let's introduce an integer-based `Math.random` equivalent
>> that can be optionally constrained to a specific range.
>>
>>
>> ```js
>> // Simple polyfill
>> Math.randomInt = Math.randomInt || function (start, end) {
>> if (arguments.length === 0) {
>> start = 0; end = Number.MAX_SAFE_INTEGER
>> } else if (arguments.length === 1) {
>> end = start; start = 0
>> }
>> start = Math.max(Math.floor(start), -Number.MAX_SAFE_INTEGER)
>> end = Math.min(Math.floor(end), Number.MAX_SAFE_INTEGER)
>>
>> return Math.floor(Math.random() * (end - start)) + start
>> }
>> ```
>>
>> You could then use it like this:
>> `array[Math.randomInt(array.length)]`. I feel in this particular case,
>> a more general solution is much more useful than just a "pick some
>> random item in an array". (Number guessing games, anyone?)
>> -
>>
>> Isiah Meadows
>> m...@isiahmeadows.com
>>
>>
>> On Thu, Jun 15, 2017 at 6:20 PM, William White <w.whi...@icloud.com>
>> wrote:
>> > And prng.pick(str), prng.pick(set) etc.?
>> >
>> > On 15 Jun 2017, at 22:34, Michał Wadas <michalwa...@gmail.com> wrote:
>> >
>> > I believe it's too specialized to be a part of Array interface.
>> >
>> > Though, I think JS should have better support for randomness, so we
>> could
>> > do:
>> >
>> > prng.pick(arr);
>> > prng.sample(arr, 5);
>> > prng.sampleWithoutRepetitions(arr, 4);
>> >
>> > On 15 Jun 2017 20:42, "Will White" <w.whi...@icloud.com> wrote:
>> >
>> > Dear es-discuss,
>> >
>> > I would like to propose Array.prototype.random, which would return a
>> random
>> > array element the same way `array[Math.floor(Math.random() *
>> array.length)]`
>> > does, because every time I want a random array element, I have to
>> remember
>> > how to do it. Do you think this is a useful addition to the language?
>> >
>> > Will White
>> > ___
>> > 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 are object initializer methods not usable as constructors?

[Michael J. Ryan]

But if you're introducing a new Class library, your writing new code... You
could almost as really setup a build chain (Babel) to support class syntax,
if you can't already target sorted browsers.


-- 
Michael J. Ryan - track...@gmail.com - http://tracker1.info

Please excuse grammar errors and typos, as this message was sent from my
phone.

On May 16, 2017 4:51 PM, "/#!/JoePea" <j...@trusktr.io> wrote:

> /#!/JoePea
>
>
> On Mon, May 15, 2017 at 6:16 PM, Jordan Harband <ljh...@gmail.com> wrote:
> > You seem to be suggesting that ES6 should be making it easier for you to
> > reimplement a core ES6 language feature. If you want `class`, can you not
>
> Yeah, sure, why not? Allow library authors to do awesome things like
> provide libraries for multiple inheritance that aren't hacks.
>
> ```js
> import Bar from './Bar'
> import Baz from './Baz'
> import multiple from 'multiple-inheritance-library-by-some-author'
>
> class Foo extends multiple(Bar, Baz) {}
> ```
>
> > use `class`? That's what users who have access to ES6+ environments are
> > likely to do anyways.
>
> ES6 classes don't have protected or private members, but an author's
> `Class` tool might.
>
> Not everyone is writing ES6 in a shiny new app. There's large outdated
> code bases. It'd be convenient for a tool like `Class` to work on old
> code, and not fail on new code.
>
> >
> > It's also worth noting that someone could do `constructor: () => {}` or
> > `constructor: function *() {}` and `new`ing them would fail the same way.
>
> Yes, we can't prevent all the bad usages, but those are obviously not
> meant to work. Concise methods aren't obviously going to fail,
> especially considering that they are not really called "concise
> methods" by most people, but more like "shorthands", and by that
> terminology the layman is going to expect them to work. Arrow function
> and generatos are very explicitly different, and you have to actually
> know what they are in order to use them.
>
> There's always going to be some way to make some library fail, but
> that doesn't mean we should add more ways to make code fail when we
> can avoid it. Arrow functions and generators are necessary for a
> purpose. However, making concise methods that don't use the keyword
> `super` non-constructable doesn't really have any great purpose, it
> only makes certain code fail in needless ways...
>
> >
> > On Mon, May 15, 2017 at 5:25 PM, /#!/JoePea <j...@trusktr.io> wrote:
> >>
> >> > Because they're methods, not functions. The distinction between the
> >> > two was merely semantic in ES5, but now it's mechanical, due to
> >> > super(); constructing something intended as a method would make
> >> > super() behave in confusing and unintuitive ways, so methods just
> >> > don't have a constructor any more.
> >>
> >> You are correct for app authors, but wrong for library authors. A
> >> library author may easily like to make an object that contains ES5
> >> constructors, and writing them like
> >>
> >> ```
> >> let ctors = {
> >>   Foo() {},
> >>   Bar() {},
> >> }
> >> ```
> >>
> >> is simply simple.
> >>
> >> For example, suppose a library author releases a `Class` function for
> >> defining classes, it could be used like this:
> >>
> >> ```
> >> const Animal = Class({
> >>   constructor: function() {
> >> console.log('new Animal')
> >>   }
> >> })
> >> ```
> >>
> >> but most JS authors who don't know about these pesky new JavaScript
> >> language internals might be inclined to write:
> >>
> >>
> >> ```
> >> const Animal = Class({
> >>   constructor() {
> >> console.log('new Animal')
> >>   }
> >> })
> >> ```
> >>
> >> If the `Class` implementation returns that "constructor", then when
> >> the user does `new Animal` they will get an unexpected error, and that
> >> is not ideal at all for a dynamic language like JavaScript.
> >>
> >> What's even stranger is that the `Class` implementation can wrap the
> >> concise method with a [[Construct]]able function and call the concise
> >> method with `.call` or `.apply` and it will work! But that is simply
> >> just messy and ugly.
> >>
> >> So why prevent it from working only sometimes? It would be much better
> >> for it to just work all the time, and make restrictions only when
> >> `

Re: Default values for specified properties

[Michael J. Ryan]

I always assumed it was an implementation detail historically... stack is
also not enumerated, though message is more surprising... I tend to
remember for logging/server purposes in particular, and call it out in my
clone library, as I've been hit by it many times.

-- 
Michael J. Ryan - track...@gmail.com - http://tracker1.info

Please excuse grammar errors and typos, as this message was sent from my
phone.

On Apr 21, 2017 4:21 AM, "T.J. Crowder" <tj.crow...@farsightsoftware.com>
wrote:

> On Fri, Apr 21, 2017 at 12:11 PM, Michael J. Ryan <track...@gmail.com>
> wrote:
>
>> I've always felt that made cloning and serializing Error based instances
>> particularly fun.
>>
>
> Well, the one on `Error.prototype` is just the `""` default anyway. But
> yes, the fact that [`Error`][1] makes the `message` "own" property it
> creates non-enumerable is slightly surprising. I'm guessing there's history
> there. :-)
>
> -- T.J. Crowder
>
> [1]: http://www.ecma-international.org/ecma-262/7.0/index.html#
> sec-error-message
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Default values for specified properties

[Michael J. Ryan]

I've always felt that made cloning and serializing Error based instances
particularly fun.

-- 
Michael J. Ryan - track...@gmail.com - http://tracker1.info

Please excuse grammar errors and typos, as this message was sent from my
phone.

On Apr 20, 2017 9:40 PM, "T.J. Crowder" <tj.crow...@farsightsoftware.com>
wrote:

> Fairly basic specification comprehension question: Is it correct that the
> `message` property of `Error.prototype` is specified as non-enumerable,
> because [its definition][1] doesn't explicitly say otherwise and so the
> default properties listed in Table 4 of [Property Attributes][2] apply?
>
> -- T.J. Crowder
>
> [1]: https://tc39.github.io/ecma262/#sec-error.prototype.message
> [2]: https://tc39.github.io/ecma262/#sec-property-attributes
>
> ___
> 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: Strict Relational Operators

[Michael J. Ryan]

That's part of why I suggested it... My mention of Object.* Was mainly that
it could defer to a common base class/constructor implementation for
comparison.  And that a string and number implementation should be
provided...

I'm also good with having non-matching types return undefined while
matching types is a Boolean.

Object.* could just defer to the prototype implementation of the first
value.. null or undefined always returning undefined.

-- 
Michael J. Ryan - track...@gmail.com - http://tracker1.info

Please excuse grammar errors and typos, as this message was sent from my
phone.

On Apr 12, 2017 7:04 AM, "Darien Valentine" <valentin...@gmail.com> wrote:

> > Personally I think `a < b` should just become a compile error if the
> types are not number.
>
> Breaking stuff aside, I think this is an important point. The fact that
> the LT/GT operators do work on strings is a source of bugs. As with default
> sort, I’ve seen code written a number of times where it was evident the
> author expected the behavior would be more like `Intl.Collator.prototype.
> compare`.
>
> Unless I’m missing some important common use case for comparing strings
> based on byte values (`assert('a' > 'B')`), I think `Number.gt`,
> `Number.gte`, `Number.lt`, `Number.lte` would be a good solution.
>
> On Wed, Apr 12, 2017 at 5:09 AM, T.J. Crowder <
> tj.crow...@farsightsoftware.com> wrote:
>
>> > Personally I think `a < b` should just become a compile error if the
>> types are not number. TypeScript?
>>
>> I'm not following you. JavaScript variables don't have types, so it can't
>> become a compile-time error; and making it one would *massively* break the
>> web. (Yes, you can use TypeScript to get types if you like, but we're not
>> talking about TypeScript.)
>>
>> > ...that's a separable concern which should not be part of the
>> operator's behaviour IMO...
>>
>> There's no talk of changing how `<` and `>` (or `<=` and `>=`) work.
>>
>> But just as we have `==` (loose, coercing) and `===` (strict,
>> non-coercing), the discussion is about having strict non-coercing versions
>> of `<`, `>`, `<=`, and `>=`.
>>
>> -- T.J. Crowder
>>
>>
>> On Wed, Apr 12, 2017 at 10:00 AM, Alexander Jones <a...@weej.com> wrote:
>>
>>> Personally I think `a < b` should just become a compile error if the
>>> types are not number. TypeScript?
>>>
>>> If you want to also check that they are both number (that's surely what
>>> we mean here and not that they are both string!) and return `false` if not,
>>> that's a separable concern which should not be part of the operator's
>>> behaviour IMO. It would appear to just mask fundamental typing errors,
>>> unless I am missing some perspective?
>>>
>>> Alex
>>>
>>> On Wed, 12 Apr 2017 at 09:02, T.J. Crowder <
>>> tj.crow...@farsightsoftware.com> wrote:
>>>
>>>> Grr, there's always something. I forgot to mention that solving this
>>>> with functions is an option because short-circuiting isn't an issue, both
>>>> operands have to be evaluated by these relational operators anyway. So
>>>> unlike the motiviations for infix functions or macros or whatever, we don't
>>>> have that issue here.
>>>>
>>>> -- T.J. Crowder
>>>>
>>>>
>>>> On Wed, Apr 12, 2017 at 8:56 AM, T.J. Crowder <
>>>> tj.crow...@farsightsoftware.com> wrote:
>>>>
>>>> Very interesting stuff so far.
>>>>
>>>> My take on some options, organized into sections:
>>>>
>>>> * Solving it in userland
>>>> * Using symbolic operators
>>>> * Using functions
>>>> * Using non-symbolic operators
>>>>
>>>> # Solving it in userland:
>>>>
>>>> Anyone wanting strict relational operators today can readily give
>>>> themselves functions for it:
>>>>
>>>> ```js
>>>> const lt = (a, b) => typeof a === typeof b && a < b;
>>>> ```
>>>>
>>>> Usage:
>>>>
>>>> ```js
>>>> if (lt(a, b)) {
>>>> // ...
>>>> }
>>>> ```
>>>>
>>>> So the question is whether the value of having a standard way of
>>>> expressing this is worth the cost of adding it?
>>>>
>>>> Playing into that is that various options come with varying costs:
>>>>
>>>> * Using symbolic operators has a

Re: Re: Strict Relational Operators

[Michael J. Ryan]

Thinking on it... (Number|Object|String) .strict(Equal|Greater|Less...)
Methods (a, b) might be better...  If either value isn't a match for the
bound type, it's a false, even if both sides are equal...

Ex,.

Number.strictEqual(null, null)  false

Object.strictEqual(1, 1)  false
...

If you're doing a strict compare, one can presume you should know what
you're comparing.


-- 
Michael J. Ryan - track...@gmail.com - http://tracker1.info

Please excuse grammar errors and typos, as this message was sent from my
phone.

On Apr 11, 2017 10:46 PM, "felix" <feli...@gmail.com> wrote:

> Maybe every operator can have a non-coercing variant?
>
> One possible syntax is to have a modifier on operators
> x = a (<) b (+) c (&&) (!)d;
> if (x (!=) y) ...
>
> Another possible syntax is to have a modifier on expressions
> x = #(a < b + c && !d)
> if #(x != y) ...
>
> On Tue, Apr 11, 2017 at 7:48 PM, Darien Valentine <valentin...@gmail.com>
> wrote:
> > Although I’m unsure if this is wise given there are already eleven
> symbols
> > that are combinations of `=` and `<`/`>`, for symmetry with `==` and
> `===`
> > I’d imagine something like this:
> >
> > ```
> > COERCIVE  STRICT
> >> =>=
> > < =<=
> >>==>==
> > <==<==
> > ```
> >
> > Could also follow the pattern `>==` (strict GT) and `<===` (strict GTE),
> > which avoids the awkwardness of the latter two sharing opening chars with
> > `=>`, but that seems more ambiguous since `>==` doesn’t let you infer
> > whether it means strict GT or strict GTE.
> >
> > It’d be nice to have this functionality built in, but I wonder if it’d
> > possibly be preferable to provide it through methods of one of the
> built-in
> > objects, rather than as operators. Functions after all are more flexible.
> >
> > ___
> > 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: Strict Relational Operators

[Michael J. Ryan]

It's definitely an interesting idea...  Been trying to consider what
character would be added to represent a strict comparison...  Perhaps @?

>@  <@  <=@ >=@ ...

Not sure how this might conflict with decorators...

-- 
Michael J. Ryan - track...@gmail.com - http://tracker1.info

Please excuse grammar errors and typos, as this message was sent from my
phone.

On Apr 10, 2017 9:48 AM, "Isiah Meadows" <isiahmead...@gmail.com> wrote:

> I'm not sure there has been prior discussion. A lot of stuff has
> already been discussed in depth, but that I don't think is one of
> them.
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
>
> On Mon, Apr 10, 2017 at 3:47 AM, T.J. Crowder
> <tj.crow...@farsightsoftware.com> wrote:
> > I'm sure there must have been discussions of adding strict relational
> > operators (e.g., non-coercing ones, the `===` versions of `<`, `>`, `<=`,
> > and `>=`), but I'm not having a lot of luck finding those discussions.
> > Searching "strict relational
> > site:https://mail.mozilla.org/pipermail/es-discuss/; and on
> esdiscuss.org
> > doesn't turn up anything relevant.
> >
> > Does anyone have a link handy? I'm not trying to start a new discussion,
> > just keen to read what's already been discussed.
> >
> > Thanks,
> >
> > -- 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

Re: Proposal: Boolean.parseBoolean

[Michael J. Ryan]

I slightly disagree... mainly in that as it stands, we have a fairly loose
type coercion system that allows almost anything to be coerced into a
boolean... in this case "parse" at least in my mind means that it should
cover the most common use cases.   I understand that Boolean("false")
doesn't currently work this way, and why Date.parse doesn't give a date
instance is a bit beyond me.

With my suggested polyfill your use case would work as expected...
However, JS interacts with more than just serialized results from JS.  It
interacts with input from multiple systems, sources, users and good/bad the
content of users.  The type coercion as it exists for boolean is in order
to provide for simplistic validation... why an empty string coerces false,
for example.  Much like we have defined "falsey" values in JS, I think that
Boolean.parse should have common truthy values/strings that can predictably
be converted as a true, where all else is false.

If all it does is:

input => String(input).toLowerCase() === 'true';

what is the point of extending Boolean?


-- 
Michael J. Ryan - http://tracker1.info

On Mon, Mar 20, 2017 at 10:47 PM, Dmitry Soshnikov <
dmitry.soshni...@gmail.com> wrote:

> On Mon, Mar 20, 2017 at 4:59 PM, Michael J. Ryan <track...@gmail.com>
> wrote:
>
>> My suggestion for a polyfill.
>>
>> if (!Boolean.parse) {
>>   Boolean.parse = function(input) {
>> // return false if it is already falsy
>> if (!input) return false;
>>
>> var expr = String(input);
>>
>> // return false if it's reasonably too long of a string
>> if (expr.length > 10) return false;
>>
>> // test trimmed input against truthy values
>> return (/^(-?1|y|t|yes|true)$/).test(expr.trim().toLowerCase());
>>   }
>> }
>>
>> -1/1 are common database boolean/bit fields
>> y/yes also common inputs for truthiness
>> t/true also common for truthiness
>>
>
> Yeah, these might be good in general, although I'd like to reduce the
> proposal to minimum vital version, and JS related. The problem we are
> trying to solve is to parse `"false"` as `false`. It's not possible with
> `Boolean('false')` today. And all the JSON.parse, and regexp manipulations
> are too low-lever implementation details; users want good semantic library!
> :)
>
> So:
>
> ```
> Boolean.parse('true'); // true
> Boolean.parse('false'); // false
> ```
>
> That's all we need for now, and already will be much better semantic
> alternative too all existing "non-semantic building material".
>
> Dmitry
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Boolean.parseBoolean

[Michael J. Ryan]

My suggestion for a polyfill.

if (!Boolean.parse) {
  Boolean.parse = function(input) {
// return false if it is already falsy
if (!input) return false;

var expr = String(input);

// return false if it's reasonably too long of a string
if (expr.length > 10) return false;

// test trimmed input against truthy values
return (/^(-?1|y|t|yes|true)$/).test(expr.trim().toLowerCase());
  }
}

-1/1 are common database boolean/bit fields
y/yes also common inputs for truthiness
t/true also common for truthiness

These account for pretty much every case of truthy stored values I've seen
in the wild.

--- Dmitry, sorry, meant to reply-all the first time, also refactored the
polyfill slightly to better account for potentially too long an input value.


-- 
Michael J. Ryan - http://tracker1.info

On Mon, Mar 20, 2017 at 4:41 PM, Michael J. Ryan <track...@gmail.com> wrote:

> I would add case insensitive "t", "y", "yes", 1, -1 as well
>
>
> --
> Michael J. Ryan - track...@gmail.com - http://tracker1.info
>
> Please excuse grammar errors and typos, as this message was sent from my
> phone.
>
> On Mar 20, 2017 11:54 AM, "Dmitry Soshnikov" <dmitry.soshni...@gmail.com>
> wrote:
>
>> On Thu, Mar 16, 2017 at 1:55 PM, Dmitry Soshnikov <
>> dmitry.soshni...@gmail.com> wrote:
>>
>>> Similar to `Number.parseInt`, the `Boolean.parseBooelan` might be useful
>>> for "boolean strings" retrieved from some string-based storages, which do
>>> not support other types at serialization.
>>>
>>> ```
>>> Boolean.parseBoolean('true'); // true
>>> Boolean.parseBoolean('false'); // false
>>> ```
>>>
>>>
>> OK, here the actual proposed spec for it: https://gist.github.com/Dmitry
>> Soshnikov/5ee1a7d51d8dbe159ae917876b27f36a
>>
>> I made it plain simple (anything which is not case-insensitive `"true"`
>> is `false`), and copy-pasted from Java.
>>
>> Dmitry
>>
>> ___
>> 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: Boolean.parseBoolean

[Michael J. Ryan]

I would add case insensitive "t", "y", "yes", 1, -1 as well


-- 
Michael J. Ryan - track...@gmail.com - http://tracker1.info

Please excuse grammar errors and typos, as this message was sent from my
phone.

On Mar 20, 2017 11:54 AM, "Dmitry Soshnikov" <dmitry.soshni...@gmail.com>
wrote:

> On Thu, Mar 16, 2017 at 1:55 PM, Dmitry Soshnikov <
> dmitry.soshni...@gmail.com> wrote:
>
>> Similar to `Number.parseInt`, the `Boolean.parseBooelan` might be useful
>> for "boolean strings" retrieved from some string-based storages, which do
>> not support other types at serialization.
>>
>> ```
>> Boolean.parseBoolean('true'); // true
>> Boolean.parseBoolean('false'); // false
>> ```
>>
>>
> OK, here the actual proposed spec for it: https://gist.github.com/
> DmitrySoshnikov/5ee1a7d51d8dbe159ae917876b27f36a
>
> I made it plain simple (anything which is not case-insensitive `"true"` is
> `false`), and copy-pasted from Java.
>
> Dmitry
>
> ___
> 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: Standardizing conditional try/catch

[Michael J. Ryan]

Could also do like C# does and treat just `throw;` as an explicit rethrow...

 I'm also not sure a lot of optimizations are needed as this is exception
handling as otherwise mentioned.


-- 
Michael J. Ryan - track...@gmail.com - http://tracker1.info

Please excuse grammar errors and typos, as this message was sent from my
phone.

On Mar 18, 2017 12:21 PM, "T.J. Crowder" <tj.crow...@farsightsoftware.com>
wrote:

> I don't see optimization being a big deal, this is exception processing
> after all.
>
> I was also thinking any expression:
>
> ```js
> try {
> // ...
> }
> catch (e if arbitraryExpression1Here) {
> // ...handle case 1
> }
> catch (e if arbitraryExpression2Here) {
> // ...handle case 2
> }
> ```
>
> ...which would essentially be:
>
> ```js
> try {
> // ...
> }
> catch (e) {
> if (arbitraryExpression1Here) {
> // ...handle case 1
> } else if (arbitraryExpression2Here) {
> // ...handle case 2
> } else {
> throw e;
> }
> }
> ```
>
> ...but without messing up the reported source of the error/stack (I'm
> looking at you, IE11).
>
> -- T.J. Crowder
>
>
> On Sat, Mar 18, 2017 at 6:06 PM, Jordan Harband <ljh...@gmail.com> wrote:
>
>> If the condition can be just "any javascript", wouldn't that potentially
>> impede optimizations? Hopefully implementors can weigh in here, since
>> non-implementor performance intuition (like mine) is often off base.
>>
>> On Sat, Mar 18, 2017 at 9:16 AM, kdex <k...@kdex.de> wrote:
>>
>>> I'm not sure if embedding this idea into the language will make future
>>> ideas about true pattern matching harder to implement or not.
>>> Destructuring assignments are pretty slow from what I've measured, and
>>> they still made it in, so I hardly see performance being a showstopper here.
>>>
>>> On Saturday, March 18, 2017 12:18:22 PM CET Michael J. Ryan wrote:
>>> > The if condition doesn't need to be limited to instance of...
>>> >
>>> > catch (err if !isNaN(err.status))
>>> >
>>> > Aside: entering code in a phone is hard...
>>> >
>>> > > `instanceof` doesn't work across realms (iframes, for example). If we
>>> > > introduced conditional catch blocks, I'd want a more reliable
>>> matching
>>> > > mechanism than instanceof.
>>> > >
>>> > > On Fri, Mar 17, 2017 at 5:01 PM, Zach Lym <zach...@indolering.com>
>>> wrote:
>>> > >
>>> > >> Firefox supports the following conditional `catch` syntax:
>>> > >>
>>> > >> try {
>>> > >> let result = await ();
>>> > >> } catch (e if e instanceof ErrorType) {
>>> > >> ...
>>> > >> }
>>> > >>
>>> > >>
>>> > >> This was originally implemented in Spidermonkey as part of an ES
>>> proposal
>>> > >> around 2000, but it was rejected for unknown reasons [0]. A 2012
>>> email to
>>> > >> this list suggesting standardization of the syntax was passed over
>>> in favor
>>> > >> of waiting for a generic pattern matching facility [0][1].  Later
>>> > >> discussion suggests that the pattern matching proposal would have
>>> been very
>>> > >> slow [2]. A proposal for a Java-like type-based conditional was
>>> proposed in
>>> > >> 2016, but was criticized for lacking generality [2].
>>> > >>
>>> > >> If the above summary is accurate, I would like to try to
>>> standardize the
>>> > >> vanilla syntax once again.  It's imperative, general, and doesn't
>>> preclude
>>> > >> the use of any hypothetical pattern matching functionality.
>>> > >>
>>> > >> Javascript's control flow has improved dramatically in recent years:
>>> > >> promises got rid of callbacks, `async`/`await` clipped promise
>>> chains, and
>>> > >> classes make it easy to create custom Error objects that preserve
>>> > >> stacktraces.  Conditional catch is the last bit of syntax needed to
>>> make JS
>>> > >> look like it was designed to handle asynchronous functions.
>>> > >>
>>> > >> Thoughts?
>>> > >>
>>> > >> -Zach Lym
>>> > >>
>>> > >> 

Re: Standardizing conditional try/catch

[Michael J. Ryan]

The if condition doesn't need to be limited to instance of...

catch (err if !isNaN(err.status))

Aside: entering code in a phone is hard...

-- 
Michael J. Ryan - track...@gmail.com - http://tracker1.info

Please excuse grammar errors and typos, as this message was sent from my
phone.

On Mar 17, 2017 11:29 PM, "Jordan Harband" <ljh...@gmail.com> wrote:

> `instanceof` doesn't work across realms (iframes, for example). If we
> introduced conditional catch blocks, I'd want a more reliable matching
> mechanism than instanceof.
>
> On Fri, Mar 17, 2017 at 5:01 PM, Zach Lym <zach...@indolering.com> wrote:
>
>> Firefox supports the following conditional `catch` syntax:
>>
>> try {
>> let result = await ();
>> } catch (e if e instanceof ErrorType) {
>> ...
>> }
>>
>>
>> This was originally implemented in Spidermonkey as part of an ES proposal
>> around 2000, but it was rejected for unknown reasons [0]. A 2012 email to
>> this list suggesting standardization of the syntax was passed over in favor
>> of waiting for a generic pattern matching facility [0][1].  Later
>> discussion suggests that the pattern matching proposal would have been very
>> slow [2]. A proposal for a Java-like type-based conditional was proposed in
>> 2016, but was criticized for lacking generality [2].
>>
>> If the above summary is accurate, I would like to try to standardize the
>> vanilla syntax once again.  It's imperative, general, and doesn't preclude
>> the use of any hypothetical pattern matching functionality.
>>
>> Javascript's control flow has improved dramatically in recent years:
>> promises got rid of callbacks, `async`/`await` clipped promise chains, and
>> classes make it easy to create custom Error objects that preserve
>> stacktraces.  Conditional catch is the last bit of syntax needed to make JS
>> look like it was designed to handle asynchronous functions.
>>
>> Thoughts?
>>
>> -Zach Lym
>>
>> [0]: https://esdiscuss.org/topic/conditional-catch-clause#content-10
>> [1]: https://esdiscuss.org/topic/conditional-catch
>> [2]: https://esdiscuss.org/topic/error-type-specific-try-catch-bl
>> ocks#content-14
>>
>> ___
>> 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: Field initializers

[Michael J. Ryan]

Interesting concept... What about inheritance?

-- 
Michael J. Ryan - track...@gmail.com - http://tracker1.info

Please excuse grammar errors and typos, as this message was sent from my
phone.

On Mar 18, 2017 12:03 AM, "just nobody" <kingd...@gmail.com> wrote:

> Would it be possible to have syntax like this? It's a feature supported by
> other JS variants in some way (CoffeeScript, TS) that feels missing from
> the spec. It's mainly useful as a convenient, terse way of setting
> properties of an object on initialization.
>
> ```js
> class Rectangle {
>   constructor (this.x, this.y, this.width, this.height) {}
>   setPosition(this.x, this.y) {}
>   setSize(this.width, this.height) {}
> }
>
> // equivalent to
> class Rectangle {
>   constructor (x, y, width, height) {
> this.x = x
> this.y = y
> this.width = width
> this.height = height
>   }
>
>   // ...
> }
>
> // for regular constructor functions as well
> function Rectangle (this.x, this.y, this.width, this.height) {}
> ```
>
> Deconstructing and argument defaults should all work similarly
> ```js
> function Point({ x: this.x, y: this.y }) {}
> function Point(this.x = 0, this.y = 0) {}
> function Point([this.x, this.y]) {}
> ```
>
>
> ___
> 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: Partial matching a string against a regex

[Michael J. Ryan]

I actually like the idea... You can do an optional matching block for
parents (...)? But that would be patterns for each character...  Having a
String.startsWith that can do a match against the start of a rexexp would
be cool.  and/or regex.testStart



-- 
Michael J. Ryan - track...@gmail.com - http://tracker1.info

Please excuse grammar errors and typos, as this message was sent from my
phone.

On Mar 4, 2017 6:36 AM, "Kent C. Dodds" <k...@doddsfamily.us> wrote:

> I can't say that I know what the repercussions of such a feature would be,
> but I'll just add that I've definitely had this use case before and feel
> like it would be really useful to have in the language. 
> --
> - Kent C. Dodds <https://twitter.com/kentcdodds>
>
> ___
> 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: Ranges

[Michael J. Ryan]

Your right... The more I think about it...

Number.range(from=0, to=Number. MAX_SAFE_INTEGER)

Is probably best, as a signature, then using .map(...) If you want a string
representation...

For that matter, wouldn't mind seeing more of the array utility methods,
like map, added to strings, iterating through each character, same as
.split('').map, but that's another discussion.

On Nov 4, 2016 3:11 AM, "Alexander Jones" <a...@weej.com> wrote:

+1000

Classic feature creep with basically zero application.


On Thursday, 3 November 2016, Isiah Meadows <isiahmead...@gmail.com> wrote:

> Could we just *not* have a `String.range`?
>
> 1. Needing a list of alphabetically sorted characters is a bit niche, even
> in the Latin alphabet.
> 2. It's ambiguous whether it should include symbols or not. (think:
> `String.range("A", "z")`)
> 3. If it's Unicode-aware, how should it act with, say, `String.range("A",
> "π")`?
>
> On Thu, Nov 3, 2016, 16:21 Viktor Kronvall <viktor.kronv...@gmail.com>
> wrote:
>
>> Even more interestingly what would `String.range("","zzz")` produce. From
>> what code point is the range started? Will this throw? Is the empty string
>> included in the iterator?
>> 2016年11月3日(木) 21:18 Viktor Kronvall <viktor.kronv...@gmail.com>:
>>
>>> Actually, after giving it some more thought for that case there is just
>>> that one possibility that makes sense.
>>>
>>> However, there are more ambiguous cases such as `String.range("AAA",
>>> "ZZZ")` (should all letters increase at once or should the rightmost letter
>>> be incremented first)
>>>
>>> Also, how would range handle the arguments in inverted order? Should
>>> there be a decreasing range or should it terminate with no elements in the
>>> iterator?
>>> 2016年11月3日(木) 21:05 kdex <k...@kdex.de>:
>>>
>>>> About the code points: `String.range` should also handle surrogate
>>>> pairs, similar to for..of does it.
>>>> About `String.range("A", "zzz")`: Do any other possibilities even make
>>>> sense?
>>>>
>>>> On Thursday, November 3, 2016 6:47:04 PM CET Viktor Kronvall wrote:
>>>> > For `String.range` what would the expected result of
>>>> > `String.range('A','zzz')` be?
>>>> >
>>>> > Is an exhaustive pattern expected?
>>>> >
>>>> > `['A','B','C',...'Z','a','b','c',...,'z','AA','AB',...]`
>>>> > 2016年11月3日(木) 19:21 Michael J. Ryan <track...@gmail.com>:
>>>> >
>>>> > > If there's a Number.range, if suggest a corresponding String.range
>>>> for
>>>> > > character ranges...  Agreed on it being a utility function over me
>>>> syntax.
>>>> > >
>>>> > > On Nov 3, 2016 10:25 AM, "Isiah Meadows" <isiahmead...@gmail.com>
>>>> wrote:
>>>> > >
>>>> > > If string ranges are based on character codes, it will (for the
>>>> Latin
>>>> > > alphabet, at least, not necessarily for other languages).
>>>> > >
>>>> > > I would prefer a function over syntax, though, since it would be
>>>> more
>>>> > > easily adopted (polyfill > syntax), and it would fit more
>>>> idiomatically
>>>> > > with the rest of the language (which also uses functions for most
>>>> > > utilities).
>>>> > >
>>>> > > Maybe a `Number.range` would work?
>>>> > >
>>>> > > ```js
>>>> > > Number.range = function *range(start, end=undefined, step=1) {
>>>> > >   if (end === undefined) [start, end] = [0, start];
>>>> > >   if (end === undefined) end = Infinity;
>>>> > >   for (let i = 0; i < end; i += step) {
>>>> > > yield i;
>>>> > >   }
>>>> > > };
>>>> > > ```
>>>> > >
>>>> > > On Thu, Nov 3, 2016, 12:56 kdex <k...@kdex.de> wrote:
>>>> > >
>>>> > > Agreed. There's no reason why `Array.range` or `[1..10]` couldn't
>>>> just
>>>> > > return a generator
>>>> > > or at least something that extends a generator, though. I wonder if
>>>

Re: Proposal of Multithread JavaScript

[Michael J. Ryan]

Workers define a clear boundary...  In Windows, only the main thread can
touch the ui..  and in Linux, threads are almost as expensive as
processes...

Just the same, I'm okay with threads, but feel that not having shared state
I'd better as you will avoid a large amount of potential bugs.  Having
clear separation still allows you to solve many problems where threading
would help in a clean and clear way.

There's been other discussions of a load a threaded module, which could
have a clear line in the sand.  I wouldn't even mind coroutines or a good,
safe csp implementation...  However, those lines would take longer to
develop safely and take longer still to lock down appropriately.

Having worked as threads and allowing a lighter weight message would negate
a lot of the negatives you mention... It doesn't have to be a serialized
message.  Adding an immutable object probative would do the trick (given
fewer hurdles).

All ui/Dom access needs to be serialized anyway, I don't think that's a
good example of why we absolutely need shared state threads.

On Nov 3, 2016 12:19 PM, "Leo Dutra"  wrote:

> I have defined many times, but you guys are in love with workers.
>
> A little look in Java's Runnables would demonstrate de nature and
> difference I'm bringing to this thread.
>
> Workers can't even modify DOM directly...
>
> Very different of go routines, Java/Scala threads etc.
>
> Workers require way more control and coding by the nature of their
> declaration and messaging. A worker lives and awaits... A thread is run
> against a living spawned process and is garbaged after the usage.
>
> ___
> 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: Ranges

[Michael J. Ryan]

If there's a Number.range, if suggest a corresponding String.range for
character ranges...  Agreed on it being a utility function over me syntax.

On Nov 3, 2016 10:25 AM, "Isiah Meadows"  wrote:

> If string ranges are based on character codes, it will (for the Latin
> alphabet, at least, not necessarily for other languages).
>
> I would prefer a function over syntax, though, since it would be more
> easily adopted (polyfill > syntax), and it would fit more idiomatically
> with the rest of the language (which also uses functions for most
> utilities).
>
> Maybe a `Number.range` would work?
>
> ```js
> Number.range = function *range(start, end=undefined, step=1) {
>   if (end === undefined) [start, end] = [0, start];
>   if (end === undefined) end = Infinity;
>   for (let i = 0; i < end; i += step) {
> yield i;
>   }
> };
> ```
>
> On Thu, Nov 3, 2016, 12:56 kdex  wrote:
>
>> Agreed. There's no reason why `Array.range` or `[1..10]` couldn't just
>> return a generator
>> or at least something that extends a generator, though. I wonder if it's
>> viable to implement
>> something akin to `.length` on ranges, which could be natural numbers or
>> `Infinity`.
>>
>> As for numbers, I don't see any issues. One issue that came up in the
>> original thread was
>> that string ranges may need a better definition, as ["A".."C"] might not
>> necessarily transpile
>> to be a generator that yields "A", "B" and "C".
>>
>> On Thursday, November 3, 2016 4:46:03 PM CET Isiah Meadows wrote:
>> > I'll note, just for clarity, that Scala's `1 to 10` is technically just
>> a
>> > normal method call equivalent to `(1).to(10)`, with optional parentheses
>> > removed.
>> >
>> > Also, I'd prefer this to be a generator instead, so infinite ranges are
>> > also possible, and so it doesn't have to be eager.
>> >
>> > On Thu, Nov 3, 2016, 11:52 Hikaru Nakashima 
>> > wrote:
>> >
>> > > How about this
>> > >
>> > > ```
>> > > for ( i of Array.range(1, 10) ) { ... }
>> > > // OR
>> > > for ( i of [1..10] )  { ... }
>> > > ```
>> > >
>> > >
>> > > ___
>> > > es-discuss mailing list
>> > > es-discuss@mozilla.org
>> > > https://mail.mozilla.org/listinfo/es-discuss
>> > >
>> >
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Michael J. Ryan]

Sorry for reply...

var a = {};
Thread 1: Object.assign(a, {...});
Thread 2: Object.assign(a, {...});

So many places to blow up internally it isn't funny... Also, as I said,
even where threading is first class with locking, there are really weird
bugs when people who don't intimately understand things write code...

Having a clear worker pattern is safer...  Adding internalized immutables
to improve message passing would be nice, as would an rpc to promise
interface...

Real threads however is a truly bad idea in JS...

On Nov 2, 2016 8:31 AM, "Michael J. Ryan" <track...@gmail.com> wrote:

There is a difference between thread safety and unexpected event ordering
in a higher level language..  just because you don't think of it in the
language doesn't mean it isn't there... Also the js environments are multi
threaded, it's just those threads are for internals and abstracted away
from you in a safe way.

On Nov 2, 2016 8:26 AM, "Leo Dutra" <leodutra...@gmail.com> wrote:

> Is not a matter of being faster. Is a matter of using machine potential
> and using better internal instructions.
> JavaScript sits over libuv and engines with multithreading without using
> multithreading.
>
> And about being faster, any serious language has a simple feature like
> threads and Visual Basic should not emerge even in Microsoft specs
> discussions. What comes next? PHP?
>
> I still don't understand why you talk so much about racing conditions in a
> language which one of the main aspects is loose clojuring and racing
> condition.
>
> Who cares about thread-safety if it were never expected and if it all can
> be seamless. And where it would not be explicit?
>
>
>
>
> ___
> 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 of Multithread JavaScript

[Michael J. Ryan]

There is a difference between thread safety and unexpected event ordering
in a higher level language..  just because you don't think of it in the
language doesn't mean it isn't there... Also the js environments are multi
threaded, it's just those threads are for internals and abstracted away
from you in a safe way.

On Nov 2, 2016 8:26 AM, "Leo Dutra"  wrote:

> Is not a matter of being faster. Is a matter of using machine potential
> and using better internal instructions.
> JavaScript sits over libuv and engines with multithreading without using
> multithreading.
>
> And about being faster, any serious language has a simple feature like
> threads and Visual Basic should not emerge even in Microsoft specs
> discussions. What comes next? PHP?
>
> I still don't understand why you talk so much about racing conditions in a
> language which one of the main aspects is loose clojuring and racing
> condition.
>
> Who cares about thread-safety if it were never expected and if it all can
> be seamless. And where it would not be explicit?
>
>
>
>
> ___
> 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 of Multithread JavaScript

[Michael J. Ryan]

Given how many bugs I've dealt with involving race conditions in .Net, I
would really rather have a solid worker pattern over any internal threading
inside the main event loop in js as this thread has proposed...

Adding an rpc-like promise callback in addition to, or over message passing
would be far safer...

Internal threading may be "a solved problem" but it creates so many new
ones with really weird bugs to go with them.

On Nov 2, 2016 8:03 AM, "Bradley Meck"  wrote:

>
> > As I said... JS has mutable objects by default. The memory space SHALL
> be the same.
>
> > What is not being covered? Let it come to the surface.
>
> As stated, that single threaded access to objects and shared memory
> multi-threaded access are very different.
>
> On Wed, Nov 2, 2016 at 9:56 AM, Leo Dutra  wrote:
>
>> Message passing between two objects is a Law of Nature, broad and
>> powerful.
>> But there's more than just workers and process spawn in life.
>>
>> As I said... JS has mutable objects by default. The memory space SHALL be
>> the same.
>>
>> Atomic could handle the racing when needed and a Mutex for locking.
>>
>> What is not being covered? Let it come to the surface.
>>
>
>
> ___
> 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