{"action":"created","issue":{"url":"https://api.github.com/repos/petkaantonov/bluebird/issues/1116","repository_url":"https://api.github.com/repos/petkaantonov/bluebird","labels_url":"https://api.github.com/repos/petkaantonov/bluebird/issues/1116/labels{/name}","comments_url":"https://api.github.com/repos/petkaantonov/bluebird/issues/1116/comments","events_url":"https://api.github.com/repos/petkaantonov/bluebird/issues/1116/events","html_url":"https://github.com/petkaantonov/bluebird/issues/1116","id":157190359,"number":1116,"title":"Bluebird 4 and modern NodeJS","user":{"login":"benjamingr","id":1315533,"avatar_url":"https://avatars.githubusercontent.com/u/1315533?v=3","gravatar_id":"","url":"https://api.github.com/users/benjamingr","html_url":"https://github.com/benjamingr","followers_url":"https://api.github.com/users/benjamingr/followers","following_url":"https://api.github.com/users/benjamingr/following{/other_user}","gists_url":"https://api.github.com/users/benjamingr/gists{/gist_id}","starred_url":"https://api.github.com/users/benjamingr/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/benjamingr/subscriptions","organizations_url":"https://api.github.com/users/benjamingr/orgs","repos_url":"https://api.github.com/users/benjamingr/repos","events_url":"https://api.github.com/users/benjamingr/events{/privacy}","received_events_url":"https://api.github.com/users/benjamingr/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/petkaantonov/bluebird/labels/4.0.0","name":"4.0.0","color":"0052cc"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":8,"created_at":"2016-05-27T11:52:25Z","updated_at":"2016-06-04T10:10:17Z","closed_at":null,"body":"Just to get some discussion going:\r\n\r\nHey, a lot of things have happened since 0.x and while the API got more refined a lot of things changed in Node. I presume a lot of people will use async/await or at least generators (with Promise.coroutine) which makes some of the convenience methods less useful. \r\n\r\nI think 4.x should focus on two things: \r\n\r\n - Making it even easier to wrap libraries with a promise-based interface and small performance penalty. \r\n - Making it easier to create libraries with a promise-based interface with a small performance penalty (i.e. - faster than the promise constructor if possible).\r\n - Making it easier to debug bluebird code.\r\n\r\nI think a lot of the utility methods don't really make sense in a generator/async-await centric Node:\r\n\r\n\r\n### Join, Try and Method\r\n`Promise.join` -\r\n```\r\nPromise.join(p1,p2,p3, (r1,r2,r3) => {\r\n  // ...\r\n});\r\nconst [r1,r2,r3] = await all([p1, p2, p3]); // or yield\r\n// ...\r\n```\r\n`Pormise.try`\r\n```\r\nPromise.try(() => {\r\n    // maybe return promise here\r\n});\r\n(async () => {\r\n     // maybe return promise here\r\n}());\r\nco(function*() {\r\n   // maybe return promise here\r\n});\r\n```\r\n`Promise.method` -> `Promise.coroutine` or `async function`\r\n\r\n###Synchronous inspection\r\n\r\nI don't really see why I'd need this API in an async/await or generator setting - but I think it's worth keeping but we can simplify it - remove `.settle` completely but keep the rest.\r\n\r\n### Collections\r\n\r\n`each` and `mapSeries` are basically for loops. Map/Filter with concurrency are still useful - `map` and `filter` without them are less useful since there is no chaining benefit but are still worth keeping. \r\n \r\n### Utilities\r\n\r\n`.call` `.return` `catchReturn` `catchThrow` aren't really useful with generators or async functions."},"comment":{"url":"https://api.github.com/repos/petkaantonov/bluebird/issues/comments/223747823","html_url":"https://github.com/petkaantonov/bluebird/issues/1116#issuecomment-223747823","issue_url":"https://api.github.com/repos/petkaantonov/bluebird/issues/1116","id":223747823,"user":{"login":"vitaly-t","id":5108906,"avatar_url":"https://avatars.githubusercontent.com/u/5108906?v=3","gravatar_id":"","url":"https://api.github.com/users/vitaly-t","html_url":"https://github.com/vitaly-t","followers_url":"https://api.github.com/users/vitaly-t/followers","following_url":"https://api.github.com/users/vitaly-t/following{/other_user}","gists_url":"https://api.github.com/users/vitaly-t/gists{/gist_id}","starred_url":"https://api.github.com/users/vitaly-t/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/vitaly-t/subscriptions","organizations_url":"https://api.github.com/users/vitaly-t/orgs","repos_url":"https://api.github.com/users/vitaly-t/repos","events_url":"https://api.github.com/users/vitaly-t/events{/privacy}","received_events_url":"https://api.github.com/users/vitaly-t/received_events","type":"User","site_admin":false},"created_at":"2016-06-04T10:10:17Z","updated_at":"2016-06-04T10:10:17Z","body":"@benjamingr re-reading a few more times, I've started to think you were talking about improved promisification?\r\n\r\nIf that's the case, then it is not a good example, because promises in `pg-promises` make up for about 1% of what the library does, it is very far from some sort of a simple merge of an existing protocol with promises.\r\n\r\nThere are two types of libraries:\r\n* ones that try to merge an existing non-promise protocol with promises, while repeating the existing protocol accurately. This is where promisification is helpful\r\n* Libraries that extend existing libraries beyond promisification. For example, `pg-promise` is an extreme case, which leave almost nothing of the original protocol.\r\n\r\nIn my experience, automatic promisification is a good quick hack at solving the callback hell. All good solutions are custom-written, to allow for specifics of the library, as most usually have.\r\n"}}
{"actor":{"display_login":"vitaly-t"}}