{"action":"created","issue":{"url":"https://api.github.com/repos/zenparsing/es-observable/issues/33","labels_url":"https://api.github.com/repos/zenparsing/es-observable/issues/33/labels{/name}","comments_url":"https://api.github.com/repos/zenparsing/es-observable/issues/33/comments","events_url":"https://api.github.com/repos/zenparsing/es-observable/issues/33/events","html_url":"https://github.com/zenparsing/es-observable/issues/33","id":92023352,"number":33,"title":"Don't use the generator interface","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":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-06-30T08:23:25Z","updated_at":"2015-06-30T15:37:35Z","closed_at":null,"body":"Continuing the discussion from https://github.com/zenparsing/es-observable/issues/14 I think that while the idea of using the generator interface as a dual to iterator is novel, there is really no justification to do so. \r\n\r\nWe see that using it as the basis for the observer does not really maintain duality particularly well (as seen in #14) nor it provides the semantics required for useful observers (as seen in #32 as well as several other issues). Now that I understand the proposal a lot better:\r\n\r\n**Wouldn't it be better if we just dropped using the ES2015 generator interface for the observer?**\r\n\r\nOn the same note - wouldn't it be better to use more descriptive names for observers (like the names used in Rx, I'm quite fond of those) and not stay bound to the interface allowing us to add cancellation semantics as we please easily? \r\n\r\nI think duality is important, but leveraging the experience with the API of people like @jhusain and @blesh who actually used observables for a great extent is just as important if not more. I'm certain we can prove duality with a better named API too. \r\n\r\n\r\n-----\r\n\r\nI'm well aware that a lot of people put a lot of work into the proposal, work by people who probably have more experience and shinier PhDs than me, you have discussed and uncovered a lot of interesting issues and I don't like delaying the proposal as much as anyone else - I definitely think though that this is worth discussing."},"comment":{"url":"https://api.github.com/repos/zenparsing/es-observable/issues/comments/117231632","html_url":"https://github.com/zenparsing/es-observable/issues/33#issuecomment-117231632","issue_url":"https://api.github.com/repos/zenparsing/es-observable/issues/33","id":117231632,"user":{"login":"zenparsing","id":5995084,"avatar_url":"https://avatars.githubusercontent.com/u/5995084?v=3","gravatar_id":"","url":"https://api.github.com/users/zenparsing","html_url":"https://github.com/zenparsing","followers_url":"https://api.github.com/users/zenparsing/followers","following_url":"https://api.github.com/users/zenparsing/following{/other_user}","gists_url":"https://api.github.com/users/zenparsing/gists{/gist_id}","starred_url":"https://api.github.com/users/zenparsing/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/zenparsing/subscriptions","organizations_url":"https://api.github.com/users/zenparsing/orgs","repos_url":"https://api.github.com/users/zenparsing/repos","events_url":"https://api.github.com/users/zenparsing/events{/privacy}","received_events_url":"https://api.github.com/users/zenparsing/received_events","type":"User","site_admin":false},"created_at":"2015-06-30T15:37:35Z","updated_at":"2015-06-30T15:37:35Z","body":"> The awkward priming they require, not to mention the \"infinite\" loop, is a sign of a pretty major impedance mismatch.\r\n\r\nBut that's just standard fare for any data sink that you write using a generator function.  Are you suggesting that developers shouldn't write data sinks with generator functions?\r\n\r\n> confusing things by matching the related-but-separate generator interface makes people think observers have something to do with generators, when they do not\r\n\r\nI must say that I disagree here.  If you introduced `onNext`, `onCompleted`, and `onError`, they would have the **exact** same semantics as `next`, `return`, and `throw` do for data sinks implemented with generator functions. (I suppose that you could quibble over the return value of the methods, though.)\r\n\r\nAgain, should programmers not use generator functions as data sinks?\r\n"}}