Promise.allSettled() - why string?
Hello,
If it’s not too awkward of a question to ask: were object methods
rather than string comparison considered for Promise.allSettled()?
For example, if I write this:
-
Promise.allSettled(promises).then( results => {
results.forEach( r => {
if (r.status === "rejectd") {
// Failure …
}
else {
// Success!
}
} );
} );
-
… the code won’t complain about the typo but instead just “do the wrong thing”.
But, if the way to parse allSettled()’s resolution were object methods instead,
it could be this:
-
Promise.allSettled(promises).then( results => {
results.forEach( r => {
if (r.isRejectd()) {
// Failure …
}
else {
// Success!
}
} );
} );
-
… which will usefully cause an exception/rejection that pinpoints the problem
in my code.
Was this pattern perhaps considered and rejected? Or is there some
liability to the object methods relative to the string comparison that I’m not
seeing? If so, what was/is the rationale there?
Thank you for your time!
cheers,
-Felipe Gasper
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Promises: unhandled rejections and finally()
Hi Logan,
Thank you .. that makes sense. I’m not sure why now but I had in mind that
finally() creates a “passthrough” promise that doesn’t affect its parent
promise’s resolved/rejected status.
Cheers,
-Felipe
> On Mar 28, 2020, at 21:40, Logan Smyth wrote:
>
>
> > Could someone point me to something that would help me to understand the
> > logic here? It looks like the first finally() is getting a “free pass”
> > while only the 2nd and subsequent ones trigger their own
> > unhandled-rejection warnings.
>
> I think the best place to start in understanding this would be to step back
> and make sure you understand what it is that triggers these errors. Node
> triggers these errors when a promise object has been rejected but has no
> handlers to do respond to the rejection. I forget exactly what point Node
> checks for handlers these days, if that point is at the end of the job
> execution or on GC of promises now or what but that's not important for this
> case.
>
> Let's look at your example. I'm also simplifying it to
> ```
> var p = Promise.reject(789);
> var one = p.finally(() => {});
> var two = p.finally(() => {});
> var three = p.finally(() => {});
> ```
>
> 1)
> ```
> var p = Promise.reject(789);
> ```
> There is only one promise here, `p`, and it has no handlers ever attached to
> it so there is nothing to handle the rejection error, hence the single
> uncaught rejection error.
>
> 2)
> ```
> var p = Promise.reject(789);
> var one = p.finally(() => {});
> ```
> There are 2 promises here, `p`, which has one handler (the `finally` that
> will take the rejection of `p` and in turn reject `one`) and `one`, which has
> no handlers attached, so you again get a single uncaught rejection. It as not
> that the first "finally" gets a "free pass", it is that rejections from `p`
> are no longer uncaught, but you have added a new promise that is uncaught, so
> the overall number of uncaught rejections does not change.
>
> 3)
> ```
> var p = Promise.reject(789);
> var one = p.finally(() => {});
> var two = p.finally(() => {});
> ```
> Hopefully you can see where this is going. `p` now has 2 handlers attached so
> its rejection isn't uncaught, but now both `one` and `two` have no handlers,
> so _both_ will trigger an uncaught rejection error.
>
> 4)
> ```
> var p = Promise.reject(789);
> var one = p.finally(() => {});
> var two = p.finally(() => {});
> var three = p.finally(() => {});
> ```
> And finally now we have `one`, `two` and `three` all with no handlers
> attached, so you will get three uncaught rejection errors.
>
> Hope that helps!
>
>
>> On Sun, Mar 29, 2020 at 9:03 AM Felipe Gasper
>> wrote:
>> Hello,
>>
>> In node 12 as well as the latest Chrome and FF (all on macOS) I see the
>> following:
>>
>> -
>> var y,n; var p = new Promise( (yy,nn) => { y=yy; n=nn } ); n(789);
>> ==> produces 1 unhandled-rejection warning
>>
>> var y,n; var p = new Promise( (yy,nn) => { y=yy; n=nn } ); p.finally( () =>
>> {} ); n(789);
>> ==> produces 1 unhandled-rejection warning
>>
>> var y,n; var p = new Promise( (yy,nn) => { y=yy; n=nn } ); p.finally( () =>
>> {} ); p.finally( () => {} ); n(789);
>> ==> produces 2 unhandled-rejection warnings
>>
>> var y,n; var p = new Promise( (yy,nn) => { y=yy; n=nn } ); p.finally( () =>
>> {} ); p.finally( () => {} ); p.finally( () => {} ); n(789);
>> ==> produces 3 unhandled-rejection warnings
>>
>> -
>>
>> Could someone point me to something that would help me to understand the
>> logic here? It looks like the first finally() is getting a “free pass” while
>> only the 2nd and subsequent ones trigger their own unhandled-rejection
>> warnings.
>>
>> Thank you!
>>
>> cheers,
>> -Felipe Gasper
>> ___
>> 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
Promises: unhandled rejections and finally()
Hello,
In node 12 as well as the latest Chrome and FF (all on macOS) I see the
following:
-
var y,n; var p = new Promise( (yy,nn) => { y=yy; n=nn } ); n(789);
==> produces 1 unhandled-rejection warning
var y,n; var p = new Promise( (yy,nn) => { y=yy; n=nn } ); p.finally( () => {}
); n(789);
==> produces 1 unhandled-rejection warning
var y,n; var p = new Promise( (yy,nn) => { y=yy; n=nn } ); p.finally( () => {}
); p.finally( () => {} ); n(789);
==> produces 2 unhandled-rejection warnings
var y,n; var p = new Promise( (yy,nn) => { y=yy; n=nn } ); p.finally( () => {}
); p.finally( () => {} ); p.finally( () => {} ); n(789);
==> produces 3 unhandled-rejection warnings
-
Could someone point me to something that would help me to understand the logic
here? It looks like the first finally() is getting a “free pass” while only the
2nd and subsequent ones trigger their own unhandled-rejection warnings.
Thank you!
cheers,
-Felipe Gasper
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: RegExp lookbehind
Bump++. :) -F On 3/16/12 3:56 PM, Lea Verou wrote: After all these years, ES regular expressions still don't support lookbehind. It turns out this was discussed in late 2010 [1] and was heading towards being accepted, but the discussion just stalled. So, consider this a bump of that thread. [1]: http://www.mail-archive.com/es-discuss@mozilla.org/msg05205.html ___ 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
for..in, hasOwnProperty(), and inheritance
Hi everyone,
There is a widespread practice of doing this:
-
for (key in obj) {
if (obj.hasOwnProperty(key)) { … }
}
-
The oft-stated purpose for this pattern is to weed out code that comes
from Object.prototype. The result, though, is that we prevent iteration
through *any* inherited properties, which seems like overkill for
handling the original problem.
(Incidentally, I’m surprised that augmenting Object.prototype isn’t
warned/deprecated in ES5 Strict. It seems far easier to get people to
stop augmenting Obj.pro, which is likely to break all kinds of things,
than to get everyone to filter every for..in loop. But, anyway.)
It’s especially unproductive because it works against prototypal
inheritance patterns. e.g.:
-
var dog = { speak: function() { return arf! } };
var beagle = Object.create(dog);
beagle.colors = [white,black,brown];
var my_dog = Object.create(beagle);
my_dog.name = Chip;
-
Note that filtering via hasOwnProperty() will prevent a for..in
iteration from seeing either colors or speak.
Another example: in YUI, it’s impossible to do this
would-otherwise-be-useful pattern:
-
var base_config = { width: 600px };
…
var my_config = Object.create(base_config);
my_config.visible = false;
var widget = new Y.Widget(my_config);
-
In the example above, YUI will not see the “width” property because YUI
rejects all inherited properties when it iterates through the
configuration hash.
So, a solution I am considering for my own work defines two methods:
Object.gave(giver, key, obj)
Function.prototype.gave(key,obj)
They do what they look like: Object.gave checks if the “giver” really
“gave” the “key”ed value to the “obj”ect. The Function.prototype version
does the same but assigns the function’s prototype as “giver”. (The
original Object.gave() offloads to the prototype method if called with
just two args.)
Thus:
--
var HOP =
Object.prototype.hasOwnProperty.call.bind(Object.prototype.hasOwnProperty);
Object.gave = function(giver,key,obj) {
if (arguments.length === 2) {
Function.prototype.gave.apply(this,arguments);
}
var last_prototype;
while ( obj !== giver ) {
if (HOP(obj,key) || (obj === last_prototype)) return false;
last_prototype = obj;
obj = Object.getPrototypeOf(obj);
}
return true;
};
Function.prototype.gave = function(key,obj) {
return Object.gave( this.prototype, key, obj );
};
--
Then, we can do:
--
for (var key in obj) {
if (Object.gave(key,obj)) { … }
}
--
…which will still filter out anything in Object.prototype, but will
allow iteration through inherited properties.
This seems to me far more useful in general than the hasOwnProperty() check.
Thoughts?
-Felipe Gasper
cPanel, Inc.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: for..in, hasOwnProperty(), and inheritance
On 11/8/11 12:37 PM, Axel Rauschmayer wrote:
What’s the use case?
I thought I gave a pretty reasonable one before, but just in case:
In YUI, it’s impossible to use this otherwise-useful pattern:
-
var base_config = { width: 600px };
…
var my_config = Object.create(base_config);
my_config.visible = false;
var widget = new Y.Widget(my_config);
-
In the example above, YUI will not see the “width” property because
YUI rejects all inherited properties when it iterates through the
configuration hash.
Don’t forget that whenever you set a property, you only ever modify the
first object in the prototype chain.
Right…that’s why gave() walks the prototype chain unless it finds the
property *on* the object itself.
The “own property” debate mainly exists, because objects are (ab)used as
dictionaries. Then you don’t want inherited entries such as toString.
I disagree. That’s actually the crux of what I’m getting at.
IMO, you actually do want “inherited entries”; what you don’t want are
specifically those things inherited from Object.prototype. Weeding out
*all* inherited properties assumes that there is no legitimate use case
for objects inheriting from other objects…which defeats the whole
purpose of stuff like Object.create().
-FG
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: for..in, hasOwnProperty(), and inheritance
On 11/8/11 1:17 PM, Axel Rauschmayer wrote:
What’s the use case?
In YUI, it’s impossible to use this otherwise-useful pattern:
-
var base_config = { width: 600px };
…
var my_config = Object.create(base_config);
my_config.visible = false;
var widget = new Y.Widget(my_config);
-
In the example above, YUI will not see the “width” property because
YUI rejects all inherited properties when it iterates through the
configuration hash.
Got it, you want to non-destructively modify base_config. It is kind
of tricky to know when to stop traversing the prototype chain, …
Actually, have you ever seen a use case of wanting to prevent iteration
through inherited properties *other* than Object.prototype? (Besides
using for..in on Array objects.)
All of the examples I’ve ever seen of the problems that ensue from
for..in iteration and prototypes stem from extending Object.prototype.
Why not, then, specifically address that problem rather than preventing
all iteration through inherited properties?
-FG
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: for..in, hasOwnProperty(), and inheritance
On 11/8/11 2:19 PM, Jake Verbaten wrote: Flexibility of shared state? Are you really corrupting the state of defaults at runtime? Do you really want changes to your default options to propogate to all objects extending the defaults? It’s the same thing as redefining a method inherited from a prototype. Why would you extend the default at all if you *don’t* want changes to it to propagate to descendents? If you don’t want propagation, make a copy. This seems like a right pain in the ass to debug/maintain? In some cases, maybe; in other cases, I think not. It also can better model what’s going on: if the schema conceives of multiple objects explicitly sharing the same default, then yes, you *do* want descendents of the parent to stay in sync with the parent (unless the descendents themselves have set values). That seems very intuitive to me. If you *want* a descendent to be independent of the parent, then don’t make it a descendent; make it a copy. FWIW, the YUI thing was pretty unintuitive to me and took me a while to “debug”. -FG ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)
On 11/8/11 2:49 PM, Brendan Eich wrote:
Should ES.next provide sugar for the recommended pattern? To make it
compose with declarations and destructuring in the for head, it should
use a contextual keyword immediately after 'for':
for own (i in o) {
/body/
}
This is a small thing but it might pay off in the long run.
This is a fantastic idea, IMO.
The hasOwnProperty() thing is buggy if you create a “hasOwnProperty”
property on the object, and it’s wordy besides.
-FG
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: for..in, hasOwnProperty(), and inheritance
On 11/8/11 2:19 PM, Brendan Eich wrote:
On Nov 8, 2011, at 12:12 PM, Luke Smith wrote:
Sure. People make classes by defining function C(){} and decorating
C.prototype.method1 = function(...){...}, etc. A for-in loop on (new C) will see all the
methods, unlike the case with built-in constructors. That is an unwanted abstraction
break: we should support abstracting over user-defined and built-in functions.
I believe people decorate a class prototype directly because they
always have, and because defineProperties wasn't available for them to
declare prototype methods as not enumerable, not because they
explicitly want class proto methods to be enumerable.
Yup, that's a fact. However it contradicts Felipe's belief that only
Object.prototype might-be-enumerable properties need to be excluded,
which was my point.
Wasn’t so much a *belief* as an observation that the reasons most folks
give for wanting the hasOwnProperty() check in for..in loops are similar
to what Crockford wrote here:
http://www.yuiblog.com/blog/2006/09/26/for-in-intrigue/
…i.e., the “main” concern, esp. if you inherit objects from just
anywhere (e.g., YUI’s config objects), is Object.prototype.
The case Brendan mentions is closer to what I had in mind as a reason
for the more fine-grained control of gave(). In Brendan’s case:
---
function C(){}; C.prototype.foo = function(){};
var my_c = new C(); my_c.bar = null;
---
…it makes sense to weed out stuff from the prototype. Even then, though,
it might be equally, or more, gainful to check for:
---
for (key in my_c) {
if ( !C.gave(key,my_c) ) { … }
}
---
…or, at least, there could be multiple use cases, e.g. multiple levels
of inheritance, and I want to filter out either *just* the original
(gave/giver) or all prototypes (hasOwnProperty()).
Anyhow. Thanks to everyone for the bandwidth on the idea.
-FG
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Are some es-discuss submissions automatically blocked?
On 11/7/11 2:48 PM, David Bruant wrote: Le 06/11/2011 15:37, Axel Rauschmayer a écrit : Claus Reinke could not submit his js-tools discussion group announcement (interestingly, I could do it for him). And the email I appended underneath my signature never got through. Can someone explain the blocking criteria? I have experienced similar problems at some point. I don't know what the blocking criteria is. Maybe an anti-spam trying to be smarter than it is? I’ve had this happen, too. -FG ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: sort keys with JSON.stringify()
On 9/12/11 10:07 AM, Brian Kardell wrote: But Doug, just to clarify: You mean that the parsed objects create no predictable insertion order right? It is actually possible to use replacer to serialize keys in a particular order, and that might be enough for what he is looking for (if two objects serialized as the same string they would be equal). Almost. Actually, I want the converse: if two objects are equal, they serialize the same way. I noodled with the replacer function for a bit but wasn’t able to get something that seems to work for objects of arbitrary depth. -FG ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: sort keys with JSON.stringify()
On 9/11/11 5:05 PM, Douglas Crockford wrote:
On 11:59 AM, Felipe Gasper wrote:
Is it possible to get sorted keys:
{a:1,c:3}
…from running JSON.stringify when declaring an object thus:
{c:3,a:1}
JSON objects are unordered. If order is important, then use an array.
That’s actually my point.
What I would like is a way to have two objects with identical data
serialize the same way--ideally (but, ok, not necessarily) with keys
sorted alphabetically.
The most immediately use for such a feature is to deep-compare two
objects, but there are probably other viable applications.
There apparently is no way to do this using browsers’ native serializers
since (as has been mentioned) they usually serialize according to
for..in order, which in turn depends on insertion order. I want a
serialization that is agnostic with regards to insertion order, that
only depends on what’s in the object here and now.
Does any of the JavaScript-based serializers offer such a feature?
-FG
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
sort keys with JSON.stringify()
Hello,
Is it possible to get sorted keys:
{a:1,c:3}
…from running JSON.stringify when declaring an object thus:
{c:3,a:1}
??
-FG
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: sort keys with JSON.stringify()
But even that is implementation-specific, right?
Object key order can be completely random…at least, that’s always been
my understanding.
-F
On 9/10/11 9:32 PM, Cryptic Swarm wrote:
run it through something like this:
function sortKeys(obj) {
var ret = {}
Object.keys(obj).sort().forEach(function(name) {
ret[name] = obj[name]
})
return ret
}
before passing it to JSON.stringify
On Sat, Sep 10, 2011 at 9:14 PM, Felipe Gasper fel...@felipegasper.com
mailto:fel...@felipegasper.com wrote:
Hello,
Is it possible to get sorted keys:
{a:1,c:3}
…from running JSON.stringify when declaring an object thus:
{c:3,a:1}
??
-FG
_
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/__listinfo/es-discuss
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Object.keys(): Why no inherited properties?
Why does Object.keys() not allow, as an option, iterating through inherited properties? -FG ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.allKeys? WAS Re: Object.keys(): Why no inherited properties?
On 9/7/11 11:17 AM, David Bruant wrote: Le 07/09/2011 18:11, Felipe Gasper a écrit : On 9/7/11 11:08 AM, David Bruant wrote: Le 07/09/2011 17:33, Felipe Gasper a écrit : Why does Object.keys() not allow, as an option, iterating through inherited properties? I do not have the answer to this very question. However, if you want to iterate through all (own and inherited) enumerable properties, you can use a for-in loop. Right, but for that matter, if you want Object.keys, you can just write out a for-in loop as well and just do .hasOwnProperty(). Object.keys must be considered a convenience method; it just seems like there are lots of reasonable scenarios of wanting the inherited properties as well as the object’s own. Object.allKeys(), anyone? Object.getPropertyNames from http://wiki.ecmascript.org/doku.php?id=harmony:extended_object_api ? Or do you want to filter out non-enumerable properties? Yes. ISTM there’s a legitimate case for putting a key-lister function that includes all inherited, non-enumerable properties. -F ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: String.prototype.repeat
On 1/9/11 6:02 AM, Jorge wrote: Or perhaps to overload * ? 'a' * 5 - a Perl has the “x” operator for things like that... -FG ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
substitutes for arguments and arguments.callee in ECMAScript 5
Hi all,
I read with dismay about the deprecation of arguments.callee in
ECMAScript 5.
I can appreciate the security concerns of passing the arguments object
as a parameter to another method, but why not make that the “red flag”
action rather than nixing “arguments” entirely?
e.g. this would cause a problem:
function() {
other_func.call(this,arguments);
}
..but this would not:
function() {
var thisfunc = arguments.callee;
}
Myself, I almost always do:
function() {
other_func.apply(this,arguments);
}
...which would not present the security concerns since the arguments
object itself isn’t passed.
Where I find myself most frequently using the arguments object is to
refer to the function itself, e.g. in YUI:
a_dialog.hideEvent.subscribe( function() {
this.hideEvent.unsubscribe( arguments.callee );
console.log(This will only happen once.);
} );
Am I to understand now that ECMASCript 5 will now have me type in:
var func;
a_dialog.hideEvent.subscribe( func = function() {
this.hideEvent.unsubscribe( func );
console.log(This will only happen once.);
} );
...or, worse:
var func = function() {
this.hideEvent.unsubscribe( func );
console.log(This will only happen once.);
};
a_dialog.hideEvent.subscribe( func );
The example I first gave is simple, straightforward, and (assuming one
knows what arguments.callee is!) easy to grasp. The second is a little
quirky because of the assignment within a function call parameter. The
third is just unclear as to what the code is meant to do.
Granted, (as I have often felt like suggesting) maybe YUI should have a
“subscribeOnce” method for its CustomEvent class for what I want to do.
That aside, though, I think there are many uses for creating anonymous
functions and referring to the function itself within the execution.
Is there really no way to accomplish this moving forward?? Few will miss
“with”, and I welcome being made to set window properties explicitly,
but nixing “callee” seems just unnecessary.
-FG
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
