Mark S. Miller

@sicking Why make the thenable test configurable? Since an assimilation convention makes the thenable test a coordination point among separately developed promise/future libraries, aren't we all better off if we...

Library B and C might count on D being classified as thenable _and_ count on E being classified as _not_ thenable. If library A changes either classification, then it can...

library B: ``` var D = {then: function(callback, errback) {...}}; var E = {when: function() {... something unrelated ...}}; ``` library C: ``` var DP = Q(D); var EP =...

After A executes all these addIsThenableHook calls, is an object considered thenable iff it passes all of them or iff it passes any of them? I'm still puzzled about what...

@sicking I am assuming that B and C had already registered the test ``` Future.addIsFutureHook(function(v) { return !!v && typeof v.then === "function"; } ``` as that is the generally...

@sicking Very specifically for this example, C would register this conventional hook, in order to recognize objects such as B's D object above as a thenable. Neither of your more...

@sicking Hi Jonas, well put. But I think a configurable thenable test will in practice create all the same problems you're trying to avoid, because some popular libraries will add...

The governance is tc39. The process is that any other organization that wishes something to be in the `js:` namespace bring it to tc39 as a tc39 proposal. This was...

> The danger here is that it doesn't provide a pathway for collaboration across standards/organizations. Sure it does. Bring it to tc39. Advance it through the tc39 process.

The quoted sentence > The `js:` prefix will be reserved as the namespace for the JavaScript language only and will be governed by TC39, making the standard library a true...