5 ms·

Lile... x instanceof Promise It works for standard promises, sure there are non standard promises, ancient stuff, that to me shouldn't be used (and a lib

Lile... x instanceof Promise It works for standard promises, sure there are non standard promises, ancient stuff, that to me shouldn't be used (and a library that uses them should be avoided). So why you need that code in the first place? Also that isPromise function will not work with TypeScript, imagine you have a function that takes something that can be a promise or not (and this is also bad design in the first place), but then you want to check if the argument is a Promise, sure with `instanceof` the compiler knows that you are doing, otherwise not. Also, look at the repo, a ton of files for a 1 line function? Really? You take less time to write that function yourself than to include that library. But you shouldn't have to write that function in the first place.

staticassertion 7y ago
1) I'm not defending the implementation of is-promise. I don't care to, I'm not a javascript developer. 2) > sure there are non standard promises, ancient stuff, that to me shouldn't be used If you're building a library, or maintaining one that's been built over many years, you can't easily make calls like that.
- dragonwriter 7y ago
  > If you're building a library, or maintaining one that's been built over many years, you can't easily make calls like that. Well, you can, and in the JS ecosystem you'll often find cases where there are two libraries (or two broad classes of libraries) for a certain function that make different choices, one of which makes the simple, modern choice that doesn't support legacy, and one that does the complex, messy thing necessary to deal with legacy code, and which you use depends on your project and it's other constraints.
  - staticassertion 7y ago
    OK, then the legacy library can't easily make that choice. I'm not saying every single javascript developer should be accepting async or sync callbacks, just that some libraries are choosing to do that for legitimate reasons.
__s 7y ago
TypeScript supports 'function f(x: any): x is T' as a way to declare that if f returns true, x may pass as type T https://www.typescriptlang.org/docs/handbook/advanced-types.html#user-defined-type-guards https://www.typescriptlang.org/docs/handbook/advanced-types....
- cyral 7y ago
  This package has an index.d.ts file that utilizes exactly this.
exogen 7y ago
Your implementation is broken even if everything uses native Promises. I don't know how many times this exact thread needs to happen on HN (as it has many times before) until people realize their "no duh" implementations of things are actually worse than the thing they're criticizing. Make an iframe. In the iframe: > window.p = new Promise(() => {}); From the parent window: > window.frames[0].p instanceof Promise false Congrats! Your isPromise function was given a Promise and returned the incorrect result. The library returns the correct result. Try again!
- suyjuris 7y ago
  In case someone else is also confused by this, it seems that instanceof checks whether the objects prototype matches, and these prototypes are not shared across different contexts, which iframes are [0]. (Though I would still like to know why it works like this.) [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/instanceof#Description https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  - odensc 7y ago
    For security reasons - you can modify the prototypes and you wouldn't want iframes to inherit that.
- hombre_fatal 7y ago
  Though, let's also appreciate just how niche that case is. I'd be surprised if more than 0.5% of the JS devs reading this will ever encounter that scenario where they are reaching across VMs like that in their life. `obj instanceof Promise` and `typeof obj.then === 'function'` (is-promise) are much different checks. Frankly, I don't think either belongs in a library. You should just write that code yourself and ponder the trade-offs. Do you really just want to check if an object has a then() method or do you want to check its prototype chain?
- stagas 7y ago
  No, it was not given a Promise. It was given a foreign object from another window. If you want to inspect another window you should not be reusing code that is designed for single threaded operations. Instead, have a layer that translates, serializes, or explicitly defines an interface that the objects we are dealing with are foreign and need to be transformed. Then the abstraction implementation details of dealing with multiple windows become a concern of a single layer and not your entire codebase. Implicitly and magically treating a foreign window as this window, will fail in many subtle and unknown ways. The "brokenness" you mention is not in that implementation, it is correctly breaking, telling you that what you are doing is wrong, then you try to bypass the error instead of fixing your approach.
cyral 7y ago
Are you saying that this isPromise package will not play well with TypeScript? One of those files (index.d.ts) solves the TypeScript problem using type predicates. TypeScript WILL know that the object is a promise if it returns true.

staticassertion 7y ago

1) I'm not defending the implementation of is-promise. I don't care to, I'm not a javascript developer. 2) > sure there are non standard promises, ancient stuff, that to me shouldn't be used If you're building a library, or maintaining one that's been built over many years, you can't easily make calls like that.

dragonwriter 7y ago
> If you're building a library, or maintaining one that's been built over many years, you can't easily make calls like that. Well, you can, and in the JS ecosystem you'll often find cases where there are two libraries (or two broad classes of libraries) for a certain function that make different choices, one of which makes the simple, modern choice that doesn't support legacy, and one that does the complex, messy thing necessary to deal with legacy code, and which you use depends on your project and it's other constraints.
- staticassertion 7y ago
  OK, then the legacy library can't easily make that choice. I'm not saying every single javascript developer should be accepting async or sync callbacks, just that some libraries are choosing to do that for legitimate reasons.

__s 7y ago

TypeScript supports 'function f(x: any): x is T' as a way to declare that if f returns true, x may pass as type T https://www.typescriptlang.org/docs/handbook/advanced-types.html#user-defined-type-guards https://www.typescriptlang.org/docs/handbook/advanced-types....

cyral 7y ago
This package has an index.d.ts file that utilizes exactly this.

exogen 7y ago

Your implementation is broken even if everything uses native Promises. I don't know how many times this exact thread needs to happen on HN (as it has many times before) until people realize their "no duh" implementations of things are actually worse than the thing they're criticizing. Make an iframe. In the iframe: > window.p = new Promise(() => {}); From the parent window: > window.frames[0].p instanceof Promise false Congrats! Your isPromise function was given a Promise and returned the incorrect result. The library returns the correct result. Try again!

suyjuris 7y ago
In case someone else is also confused by this, it seems that instanceof checks whether the objects prototype matches, and these prototypes are not shared across different contexts, which iframes are [0]. (Though I would still like to know why it works like this.) [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/instanceof#Description https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- odensc 7y ago
  For security reasons - you can modify the prototypes and you wouldn't want iframes to inherit that.
hombre_fatal 7y ago
Though, let's also appreciate just how niche that case is. I'd be surprised if more than 0.5% of the JS devs reading this will ever encounter that scenario where they are reaching across VMs like that in their life. `obj instanceof Promise` and `typeof obj.then === 'function'` (is-promise) are much different checks. Frankly, I don't think either belongs in a library. You should just write that code yourself and ponder the trade-offs. Do you really just want to check if an object has a then() method or do you want to check its prototype chain?
stagas 7y ago
No, it was not given a Promise. It was given a foreign object from another window. If you want to inspect another window you should not be reusing code that is designed for single threaded operations. Instead, have a layer that translates, serializes, or explicitly defines an interface that the objects we are dealing with are foreign and need to be transformed. Then the abstraction implementation details of dealing with multiple windows become a concern of a single layer and not your entire codebase. Implicitly and magically treating a foreign window as this window, will fail in many subtle and unknown ways. The "brokenness" you mention is not in that implementation, it is correctly breaking, telling you that what you are doing is wrong, then you try to bypass the error instead of fixing your approach.

cyral 7y ago

Are you saying that this isPromise package will not play well with TypeScript? One of those files (index.d.ts) solves the TypeScript problem using type predicates. TypeScript WILL know that the object is a promise if it returns true.