3 ms·

I mean, if you have to assume deliberately adversarial action on the part of your own codebase, you may have worse problems than having to duck-type promises.

gpm 7y ago
A class with a `then` method isn't a rare thing that could only come up adversarially. Below I've linked two example from the rust std-library (I just chose that language because the documentation is really easy to search for objects which have a method name then). I think we can be sure that both booleans, and the "less than, equal to, or greater than" enum are not in fact promises. https://doc.rust-lang.org/std/primitive.bool.html#method.then https://doc.rust-lang.org/std/primitive.bool.html#method.the... https://doc.rust-lang.org/std/cmp/enum.Ordering.html#method.then https://doc.rust-lang.org/std/cmp/enum.Ordering.html#method....
- throwanem 7y ago
  What do Rust idioms have to do with Javascript?
  - gpm 7y ago
    The language has nothing to do with it. The point is just that the name "then" is a perfectly common method name. If a small standard library is using it for things that aren't promises, you can bet your ass that there are javascript libraries using it for things that aren't promises. Like I said, I just chose to look at rust first because it's documentation has a good search bar.
    - throwanem 7y ago
      The language has everything to do with it, because the language is the locus of practice. Rust practice is whatever it is, and is apparently pretty free with the use of "then" as a method name, which is fine. Javascript practice isn't the same as Rust practice, and Javascript practice includes a pretty strong norm around methods named "then". That's why the next time I run into such a method, that doesn't belong to a promise and behave the way a promise's "then" method does, will be the first time I can remember, despite having worked primarily or exclusively in Javascript since well before promises even existed. I'm sure there is an example somewhere on NPM of a wildcat "then", and that if you waste enough of your time you can find it. So what, though? People violate Rust idioms too from time to time, I'm sure. I doubt you'd argue that that calls Rust idioms themselves into question. Why does it do so with Javascript?
      - gpm 7y ago
        It doesn't call into question the idioms of either language. It does call into question the idea of programmatically deciding whether or not something is a promise based on the assumption that the idiom was followed. People bounce around between languages, especially to javascript. An expert javascript dev might not call things "then" but the many dabblers might. Going back to the original point this is a footgun, not only an avenue for malicious code to cause trouble.
        throwanem 7y ago
        So your point ultimately is that duck-typing isn't ideal? I mean, I agree, but I'm not sure where this gets us that we weren't before.
        gpm 7y ago
        I don't actually mind duck-typing. My primary point is just that you are mistaken when claiming that this bug could only be surfaced by malicious code. My secondary (somewhat implicit) point is that having an "is-promise" function is a mistake when there is no way to tell if something actually is or is not a promise. This library/function name is lying to the programmers using it about what it is actually capable of, and that's likely to create bugs.
        throwanem 7y ago
        I mind duck typing! That's why I'm so fond of Typescript, where everything that shows up where a promise should be is reliably either instanceof Promise, or instanceof something that implements Promise, or a compile-time error. Absent that evolved level of tooling, and especially in an environment still dealing with the legacy of slow standardization and competing implementations that I mentioned in another comment, you're stuck with best effort no matter what. In the case of JS and promises, because of the norm I described earlier in this thread, best effort is easily good enough to be going on with. It's not ideal, but what in engineering practice ever is?
- monkpit 7y ago
  Cypress.io has chainable .then functions but they are not await-able and the documentation clearly states they are not promises and cannot be treated as such. It’s a bad idea, but it is out there.
  - throwanem 7y ago
    I haven't used Cypress, but looking at its docs, I don't know that I'd agree its use of "then" is all that bad. I agree they'd have done better to find a different name, but this at least seems like the least possible violation of least surprise if they are going to reuse the name. At the same time, it is intensely wild to me that their "then" is an alternative to their "should", which apparently just re-executes the callback it's given until that callback stops throwing. If your tests require to be re-run an arbitrary and varying number of times in order to pass, you have problems that need to be dealt with in some better way than having your test harness paper over them automatically for you.
Turing_Machine 7y ago
https://wiki.c2.com/?TheKenThompsonHack https://wiki.c2.com/?TheKenThompsonHack

gpm 7y ago

A class with a `then` method isn't a rare thing that could only come up adversarially. Below I've linked two example from the rust std-library (I just chose that language because the documentation is really easy to search for objects which have a method name then). I think we can be sure that both booleans, and the "less than, equal to, or greater than" enum are not in fact promises. https://doc.rust-lang.org/std/primitive.bool.html#method.then https://doc.rust-lang.org/std/primitive.bool.html#method.the... https://doc.rust-lang.org/std/cmp/enum.Ordering.html#method.then https://doc.rust-lang.org/std/cmp/enum.Ordering.html#method....

throwanem 7y ago
What do Rust idioms have to do with Javascript?
- gpm 7y ago
  The language has nothing to do with it. The point is just that the name "then" is a perfectly common method name. If a small standard library is using it for things that aren't promises, you can bet your ass that there are javascript libraries using it for things that aren't promises. Like I said, I just chose to look at rust first because it's documentation has a good search bar.
  - throwanem 7y ago
    The language has everything to do with it, because the language is the locus of practice. Rust practice is whatever it is, and is apparently pretty free with the use of "then" as a method name, which is fine. Javascript practice isn't the same as Rust practice, and Javascript practice includes a pretty strong norm around methods named "then". That's why the next time I run into such a method, that doesn't belong to a promise and behave the way a promise's "then" method does, will be the first time I can remember, despite having worked primarily or exclusively in Javascript since well before promises even existed. I'm sure there is an example somewhere on NPM of a wildcat "then", and that if you waste enough of your time you can find it. So what, though? People violate Rust idioms too from time to time, I'm sure. I doubt you'd argue that that calls Rust idioms themselves into question. Why does it do so with Javascript?
    - gpm 7y ago
      It doesn't call into question the idioms of either language. It does call into question the idea of programmatically deciding whether or not something is a promise based on the assumption that the idiom was followed. People bounce around between languages, especially to javascript. An expert javascript dev might not call things "then" but the many dabblers might. Going back to the original point this is a footgun, not only an avenue for malicious code to cause trouble.
      - throwanem 7y ago
        So your point ultimately is that duck-typing isn't ideal? I mean, I agree, but I'm not sure where this gets us that we weren't before.
        gpm 7y ago
        I don't actually mind duck-typing. My primary point is just that you are mistaken when claiming that this bug could only be surfaced by malicious code. My secondary (somewhat implicit) point is that having an "is-promise" function is a mistake when there is no way to tell if something actually is or is not a promise. This library/function name is lying to the programmers using it about what it is actually capable of, and that's likely to create bugs.
        throwanem 7y ago
        I mind duck typing! That's why I'm so fond of Typescript, where everything that shows up where a promise should be is reliably either instanceof Promise, or instanceof something that implements Promise, or a compile-time error. Absent that evolved level of tooling, and especially in an environment still dealing with the legacy of slow standardization and competing implementations that I mentioned in another comment, you're stuck with best effort no matter what. In the case of JS and promises, because of the norm I described earlier in this thread, best effort is easily good enough to be going on with. It's not ideal, but what in engineering practice ever is?
monkpit 7y ago
Cypress.io has chainable .then functions but they are not await-able and the documentation clearly states they are not promises and cannot be treated as such. It’s a bad idea, but it is out there.
- throwanem 7y ago
  I haven't used Cypress, but looking at its docs, I don't know that I'd agree its use of "then" is all that bad. I agree they'd have done better to find a different name, but this at least seems like the least possible violation of least surprise if they are going to reuse the name. At the same time, it is intensely wild to me that their "then" is an alternative to their "should", which apparently just re-executes the callback it's given until that callback stops throwing. If your tests require to be re-run an arbitrary and varying number of times in order to pass, you have problems that need to be dealt with in some better way than having your test harness paper over them automatically for you.

Turing_Machine 7y ago

https://wiki.c2.com/?TheKenThompsonHack https://wiki.c2.com/?TheKenThompsonHack