Re: Existential Operator / Null Propagation Operator

[Ron Waldon]

Once upon a time, there was a fascinating proposal on this subject:
- https://github.com/sebmarkbage/ecmascript-undefined-propagation

Rather than introduce new syntax, Sebastian's proposal was to automatically
propagate `undefined` values: if we're about to throw a
dot-property-access-on-undefined error, we just return `undefined` instead.

I could find much discussion about this here, but I did find lots of
discussions about approaches involving alternative syntax.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Provide hooks for Content Security Policy (CSP)?

[Ron Waldon]

Are there CSP benefits for other JavaScript environments (e.g. Node.js)?

Would there be benefits in applying CSP at the module level? e.g. module A
has been vetted and can do these things, whilst module B is less trusted
and has strict limitations
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: PRNG - currently available solutions aren't addressing many use cases

[Ron Waldon]

>
> -- Forwarded message --
> From: "Michał Wadas" 
> To: es-discuss@mozilla.org
> Cc:
> Date: Tue, 1 Dec 2015 20:20:34 +0100
> Subject: PRNG - currently available solutions aren't addressing many use
> cases
>

...

> - not seedable
>
Chance JS is a fairly prominent high-level JavaScript library for this
purpose, has a configurable seed, implements a Mersenne Twister, does not
use Math.random(), but is likely in the PRNG class, not in the CSPRNG class:
http://chancejs.com/#seed

That said, it would be interesting if some of the ES2015 primitives had
built-in random generators: synchronous for PRNG, and asynchronous for
CSPRNG. e.g.

Boolean.random() => Boolean
Boolean.randomCS(callback?) => Promise

Number.randomInt(min, max) => Number
Number.randomIntCS(min, max, callback?) => Promise

etc...

But these can be and are implemented just fine at the user-land level. As
such, it's hard to justify making the standard library larger for this
purpose.

For CSPRNG purposes, however, it could be valuable to standardise either
Node.js crypto module, the window.crypto, or something new (that supports
seeds)?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Existential Operator / Null Propagation Operator

[Ron Waldon]

Yep. I agree now. I see that this would break loads of existing code.
Thanks.

On Fri, 30 Oct 2015, 12:23  <es-discuss-requ...@mozilla.org> wrote:

Send es-discuss mailing list submissions to
es-discuss@mozilla.org

To subscribe or unsubscribe via the World Wide Web, visit
https <https://mail.mozilla.org/listinfo/es-discuss>://
<https://mail.mozilla.org/listinfo/es-discuss>mail.mozilla.org
<https://mail.mozilla.org/listinfo/es-discuss>/
<https://mail.mozilla.org/listinfo/es-discuss>listinfo
<https://mail.mozilla.org/listinfo/es-discuss>/
<https://mail.mozilla.org/listinfo/es-discuss>es-discuss
<https://mail.mozilla.org/listinfo/es-discuss>
or, via email, send a message with subject or body 'help' to
es-discuss-requ...@mozilla.org

You can reach the person managing the list at
es-discuss-ow...@mozilla.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of es-discuss digest..."
Today's Topics:

   1. Re: Re: Existential Operator / Null Propagation Operator
  (LaurentiuMacovei) (Isiah Meadows)
   2. Re: Existential Operator / Null Propagation Operator
  (Waldemar Horwat)
   3. Re: Existential Operator / Null Propagation Operator
  (Claude Pache)
   4. Re: Map literal (Alexander Jones)

-- Forwarded message ------
From: Isiah Meadows <isiahmead...@gmail.com>
To: Ron Waldon <jokeyrh...@gmail.com>, es-discuss@mozilla.org
Cc:
Date: Thu, 29 Oct 2015 23:03:28 +
Subject: Re: Re: Existential Operator / Null Propagation Operator
(Laurentiu Macovei)

I strongly oppose. I already write a ton of code that relies on that
throwing, using that for testing purposes. I'd rather something throw
violently than to silently fail in an unexpected, potentially seemingly
unrelated place. Not even pure functional programming can act as a safety
net for implicit undefined/null access.

On Thu, Oct 29, 2015, 15:30 Ron Waldon <jokeyrh...@gmail.com> wrote:

Has anyone considering just making dot-property access return intermediate
undefined or null values by default?

Not having to introduce new syntax would be a bonus. I'm trying to think of
existing code that this would break and can't think of any good examples.

The only compatibility issue I have thought of so far is code that relies
on an Error being thrown but also does not check the value:

```js
let value;
try { value = deep.deep.deep.prop; } catch (err) { /* ... */ }
// use value without even a basic truthy test
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Death Before Confusion (was: [whatwg] Handling out of memory issues with getImageData/createImageData)

[Ron Waldon]

Android has an older onLowMemory() callback and a newer onTrimMemory()
callback:
-
http://developer.android.com/reference/android/content/ComponentCallbacks.html#onLowMemory
()
-
http://developer.android.com/reference/android/content/ComponentCallbacks2.html#onTrimMemory(int
)

iOS has something similar as well.

Is making these available in ECMAScript proper or an annex a potential
solution to this class of problem?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

JSDoc3-style operator to access property of prototype(s)

[Ron Waldon]

I've been using JSDoc 3 for documentation of JavaScript code for years now,
and it recently occurred to me that maybe the instanceMember namepath is
a candidate for inclusion in ECMAScript proper:

http://usejsdoc.org/about-namepaths.html

The # operator would effectively be syntax sugar for .prototype.

Some examples:

MyConstructor#method === MyConstructor.prototype.method; // true

class Child extends Parent {
  method () {
// TODO: do something more than Parent would
return Parent#method.call(this);
// equivalent to Parent.prototype.method.call(this);
  }
}

var args = Array#slice.call(arguments, 0);

Now, some of these examples may be anti-patterns in an ES2015 world, but I
wonder whether .prototype.foo is accessed frequently enough in enough code
(even post-ES2015) that there's some merit here.

For me, it would make argument wrangling and ES5 class code more
convenient, and it would also bring extra parity between my JSDoc content
and the actual code it documents.

Have all use cases for this idea already been squashed by ES2015? I realise
there is a high threshold for syntax changes.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Named Arrow Functions

[Ron Waldon]

For use cases that require named Functions (e.g. recursion), surely it's
not a such a big deal to either assign an Array Function to a variable
first, or use the good old trusty named Function expression or Function
statement.

var recurseExample = () = { recurseExample(); }

var recurseExample = function recurseExample () { recurseExample(); }

function recurseExample () { recurseExample(); }

I wonder if it's even a good idea to use Arrow Functions in places that do
not benefit from the new `this` behaviour? Just because code takes up fewer
characters does not necessarily mean it is easier to understand.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES8 Proposal: Optional Static Typing (Brandon Andrews)

[Ron Waldon]

 One of the first complications with types is typeof's behavior. All of
the above types would return their string conversion including bool. (In my
experience boolean is seen as verbose among C++ and C# developers.
Breaking this part of Java's influence probably wouldn't hurt to preserve
consistency for the future).

I can't see typeof changing at all. Verbose output doesn't seem like a
problem that is worth breaking backwards-compatibility to solve.

We've seen a new pattern in ES5 and continued now with ES2015:

- Array.isArray()
- Number.isNumber()
- Object.isObject()
- etc...

Perhaps this pattern just needs to be continued for all types, including
the TypedArrays (if not already being considered). I personally like this
pattern because it doesn't change typeof, and it provides an less-verbose
alternative, and it is able to be polyfilled because it's an API addition
and not a syntax change.

Other than this, I like the idea of optional static typing. I am a
little ambivalent about the syntax. I can't decide if it literally should
just be decorators, or if it deserves something more special.

Perhaps all we really need here is the ability to name decorators using
Symbols. This way, ECMA / TC39 can use real data over time to add type
decorator Symbols for the 90% case without conflicting with future code. By
virtue of being built-in Symbol-named decorators, they should still be able
to natively-optimised and statically-analysed.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: How can I synchronously determine a JavaScript Promise's state? (Domenic Denicola)

[Ron Waldon]

Apologies if this is a duplicate: I'm new to mailing lists and got a little
bit muddled.

## legacy use case

I am maintaining an existing API that includes asynchronous functions (mix
of callbacks and Promises) and synchronous functions. After some
asynchronous initialisation, the internal state settles and it is perfectly
safe to use the synchronous functions as expected.

So, I'd like to emit warnings when these synchronous functions are called
prior to a Promise being settled. That way, downstream developers will
know that they should be waiting for the Promise to settle before using
such functions.

This actually isn't too different to the XHR / Fetch APIs conceptually. We
get the ball rolling with an asynchronous API call, but there are
deterministic blocks within which we can synchronously interrogate
progress, etc.

## activity indicator use case

I use a Promise to represent a network transaction. I wish to alter the
visual state of my web app to reflect the state of this network
transaction. I can, for example, show an indeterminate progress bar whilst
the Promise is not settled.

If I am using requestAnimationFrame, or a framework like React, then the
state would be synchronously mapped to the DOM / canvas during each
execution of my render function.

I can track the state of the Promise using additional variables (as others
have suggested), but those state values already exist somewhere private per
the functioning of a Promise. I'd be duplicating work that the JavaScript
engine is already performing internally, at the risk of introducing errors
in my code.

## third-party popular libraries

The following libraries implement some form of Promise and all expose such
synchronous inspection capabilities:

- jQuery: http://api.jquery.com/deferred.state/
- Bluebird:
https://github.com/petkaantonov/bluebird/blob/master/API.md#synchronous-inspection
- Q:
https://github.com/kriskowal/q/wiki/API-Reference#state-inspection-methods
- Lie: https://github.com/calvinmetcalf/lie/blob/master/lib/promise.js#L17



 On Tue, 2 Jun 2015 at 07:31 Domenic Denicola d...@domenic.me wrote:

 I will repeat to you what I said on Specifiction:

  To get a standard API for this, you'll need to convince the JavaScript
 standard committee, as well as the browser vendors, that your use case is
 widespread and important enough to be worth the standardization and
 implementation burden, and that it cannot be achieved in any other possible
 way.
 
  So ... go!

 Looking forward to your use cases, preferably with examples showing code
 in popular libraries or apps that would benefit to illustrate how
 wide-spread those use cases are.


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

How can I synchronously determine a JavaScript Promise's state?

[Ron Waldon]

I have lodged the following question on StackOverflow:
http://stackoverflow.com/questions/30564053/how-can-i-synchronously-determine-a-javascript-promises-state

I have also lodged it as a proposal on Specifiction:
http://discourse.specifiction.org/t/how-can-i-synchronously-determine-a-javascript-promises-state/866

I have a pure JavaScript Promise (built-in implementation or poly-fill):

`var promise = new Promise(function (resolve, reject) { /* ... */ });`

From the [specification](
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-promise-objects),
a Promise can be one of:

- 'settled' and 'resolved'
- 'settled' and 'rejected'
- 'pending'

I have a use case where I wish to interrogate the Promise synchronously and
determine:

- is the Promise settled?
- if so, is the Promise resolved?

It appears there is no API for synchronous interrogation of a Promise's
state. Can we please make this part of a future specification?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: How can I synchronously determine a JavaScript Promise's state?

[Ron Waldon]

## legacy use case

I am maintaining an existing API that includes asynchronous functions (mix
of callbacks and Promises) and synchronous functions. After some
asynchronous initialisation, the internal state settles and it is perfectly
safe to use the synchronous functions as expected.

So, I'd like to emit warnings when these synchronous functions are called
prior to a Promise being settled. That way, downstream developers will
know that they should be waiting for the Promise to settle before using
such functions.

This actually isn't too different to the XHR / Fetch APIs conceptually. We
get the ball rolling with an asynchronous API call, but there are
deterministic blocks within which we can synchronously interrogate
progress, etc.

## activity indicator use case

I use a Promise to represent a network transaction. I wish to alter the
visual state of my web app to reflect the state of this network
transaction. I can, for example, show an indeterminate progress bar whilst
the Promise is not settled.

If I am using requestAnimationFrame, or a framework like React, then the
state would be synchronously mapped to the DOM / canvas during each
execution of my render function.

I can track the state of the Promise using additional variables (as others
have suggested), but those state values already exist somewhere private per
the functioning of a Promise. I'd be duplicating work that the JavaScript
engine is already performing internally, at the risk of introducing errors
in my code.

## third-party popular libraries

The following libraries implement some form of Promise and all expose such
synchronous inspection capabilities:

- jQuery: http://api.jquery.com/deferred.state/
- Bluebird:
https://github.com/petkaantonov/bluebird/blob/master/API.md#synchronous-inspection
- Q:
https://github.com/kriskowal/q/wiki/API-Reference#state-inspection-methods
- Lie: https://github.com/calvinmetcalf/lie/blob/master/lib/promise.js#L17


On Tue, 2 Jun 2015 at 07:31 Domenic Denicola d...@domenic.me wrote:

 I will repeat to you what I said on Specifiction:

  To get a standard API for this, you'll need to convince the JavaScript
 standard committee, as well as the browser vendors, that your use case is
 widespread and important enough to be worth the standardization and
 implementation burden, and that it cannot be achieved in any other possible
 way.
 
  So ... go!

 Looking forward to your use cases, preferably with examples showing code
 in popular libraries or apps that would benefit to illustrate how
 wide-spread those use cases are.

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