{"action":"created","issue":{"url":"https://api.github.com/repos/promises-aplus/promises-spec/issues/263","repository_url":"https://api.github.com/repos/promises-aplus/promises-spec","labels_url":"https://api.github.com/repos/promises-aplus/promises-spec/issues/263/labels{/name}","comments_url":"https://api.github.com/repos/promises-aplus/promises-spec/issues/263/comments","events_url":"https://api.github.com/repos/promises-aplus/promises-spec/issues/263/events","html_url":"https://github.com/promises-aplus/promises-spec/issues/263","id":313987008,"number":263,"title":"Some imprecise points in this spec","user":{"login":"dmitriz","id":2513193,"avatar_url":"https://avatars2.githubusercontent.com/u/2513193?v=4","gravatar_id":"","url":"https://api.github.com/users/dmitriz","html_url":"https://github.com/dmitriz","followers_url":"https://api.github.com/users/dmitriz/followers","following_url":"https://api.github.com/users/dmitriz/following{/other_user}","gists_url":"https://api.github.com/users/dmitriz/gists{/gist_id}","starred_url":"https://api.github.com/users/dmitriz/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dmitriz/subscriptions","organizations_url":"https://api.github.com/users/dmitriz/orgs","repos_url":"https://api.github.com/users/dmitriz/repos","events_url":"https://api.github.com/users/dmitriz/events{/privacy}","received_events_url":"https://api.github.com/users/dmitriz/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":8,"created_at":"2018-04-13T06:46:02Z","updated_at":"2018-05-05T17:55:14Z","closed_at":null,"author_association":"NONE","body":"Hopefully these can be made more precise (I'll be happy to attempt a PR if desired):\r\n\r\n---\r\n1.\r\n```md\r\nbut does not imply deep immutability.\r\n```\r\nProbably clear enough to most, but a quick example would make it even more clear to people with less experience.\r\n\r\n---\r\n2.\r\n```md\r\n2. If `onFulfilled` is a function:\r\n    i. it must be called after promise is fulfilled, with promise's value as its first argument.\r\n```\r\nDoes it actually mean \"as its only argument\"? The same for 3.i.\r\n\r\n---\r\n3.\r\n```md\r\n5. `onFulfilled` and `onRejected` must be called as functions (i.e. with no `this` value). [3.2]\r\n```\r\nWould saying \"with `this` value being `undefined`\" make it more precise?\r\n\r\n---\r\n4.\r\n```md\r\n6. `then` may be called multiple times on the same promise.\r\n```\r\nVery confusing. Any example of how this can happen?\r\n\r\n---\r\n5.\r\n```md\r\n6.1. If/when `promise` is fulfilled, all respective `onFulfilled` callbacks must execute in the order of their originating calls to `then`\r\n```\r\nIsn't there always a single `onFulfilled` callback inside `then`? What is the meaning of the \"all respective callbacks\"? \r\n\r\nWhat is the precise meaning of \"their originating call to `then`? Any example?\r\n\r\n---\r\n6.\r\n```md\r\n7.i. If either `onFulfilled` or `onRejected` returns a value `x`, run the Promise Resolution Procedure [[Resolve]](promise2, x).\r\n```\r\nMaybe it would be more clear to say \"... don't throw an exception\", as `undefined` is also a value and both are functions, so they always return a value unless throw.\r\n\r\n---\r\n7.\r\n```md\r\n7.iii. If `onFulfilled` is not a function...\r\n```\r\nHowever, it looks like in 7.i and 7.ii it was assumed this was a function. Maybe make it more precise by adding \"If ... is a function\" to those?\r\n\r\n---\r\n8.\r\n```md\r\n... assumption that x behaves at least somewhat like a promise\r\n```\r\nObviously \"somewhat like promise\" is imprecise. Any way to make it more clear?\r\n\r\n---\r\n9.\r\n```md\r\n1. If `promise` and `x` refer to the same object, reject `promise` with a `TypeError` as the reason.\r\n```\r\nAny example how that is possible in this situation? \r\n\r\nAnd why is that a `TypeError` if the reason is the objects identity, not the wrong type?\r\n\r\n---\r\n10.\r\n```md\r\n2. If x is a promise, adopt its state [3.4]:\r\n```\r\nThis feels like a circular logic, since it is inside the spec defining what promise is. Can this definition made avoid referring to promise?\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/promises-aplus/promises-spec/issues/comments/386823639","html_url":"https://github.com/promises-aplus/promises-spec/issues/263#issuecomment-386823639","issue_url":"https://api.github.com/repos/promises-aplus/promises-spec/issues/263","id":386823639,"user":{"login":"donhatch","id":12412901,"avatar_url":"https://avatars1.githubusercontent.com/u/12412901?v=4","gravatar_id":"","url":"https://api.github.com/users/donhatch","html_url":"https://github.com/donhatch","followers_url":"https://api.github.com/users/donhatch/followers","following_url":"https://api.github.com/users/donhatch/following{/other_user}","gists_url":"https://api.github.com/users/donhatch/gists{/gist_id}","starred_url":"https://api.github.com/users/donhatch/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/donhatch/subscriptions","organizations_url":"https://api.github.com/users/donhatch/orgs","repos_url":"https://api.github.com/users/donhatch/repos","events_url":"https://api.github.com/users/donhatch/events{/privacy}","received_events_url":"https://api.github.com/users/donhatch/received_events","type":"User","site_admin":false},"created_at":"2018-05-05T17:55:14Z","updated_at":"2018-05-05T17:55:14Z","author_association":"NONE","body":"> > Yes. The crucial additions are the words \"(Recommended)\" and \"known to be\".\r\n\r\n> That still feels vague. Known to whom?\r\n\r\nCorrect, \"known to be\" is vague, and I believe it's clarified reasonably in the added part of the footnote (which says the same thing @ForbesLindesay has said here, which you said you like-- the agreement is not surprising since @ForbesLindesay is in fact the author of that part of the pull request :-) )   This is a giant leap forward from the previous wording \"is a promise\", which is *self-contradictory*, and was *contradicted* in the footnote.   If we could get this improvement in, I would declare victory in this area.\r\n\r\n| All problems here are actually easy to solve by removing that section completely\r\nand leaving only the same uniform treatment of promises as thenables.\r\n\r\nThat's true, but then the spec would effectively *forbid* the optimization.  That's not an option, since the optimization is considered to be important and it simply isn't going to be removed or omitted from various existing libraries that Promises/A+ ties together.\r\n\r\nPromises/A+ certainly allows you to omit the optimization from a particular implementation (since the optimization *is* only recommended, not required, regardless of the currently sloppy wording), and such an implementation can be documented as such; i.e. its spec would forbid the optimization, making it strictly stronger than the Promises/A+ spec.  Does this meet your needs at all?  In any case, I'm afraid that's the most you're going to get from Promises/A+ in this regard."}}
{"actor":{"display_login":"donhatch"}}