{"action":"created","issue":{"url":"https://api.github.com/repos/tc39/proposal-pipeline-operator/issues/101","repository_url":"https://api.github.com/repos/tc39/proposal-pipeline-operator","labels_url":"https://api.github.com/repos/tc39/proposal-pipeline-operator/issues/101/labels{/name}","comments_url":"https://api.github.com/repos/tc39/proposal-pipeline-operator/issues/101/comments","events_url":"https://api.github.com/repos/tc39/proposal-pipeline-operator/issues/101/events","html_url":"https://github.com/tc39/proposal-pipeline-operator/issues/101","id":303423198,"number":101,"title":"Allowing 'instance methods' to be importable","user":{"login":"jakearchibald","id":93594,"avatar_url":"https://avatars1.githubusercontent.com/u/93594?v=4","gravatar_id":"","url":"https://api.github.com/users/jakearchibald","html_url":"https://github.com/jakearchibald","followers_url":"https://api.github.com/users/jakearchibald/followers","following_url":"https://api.github.com/users/jakearchibald/following{/other_user}","gists_url":"https://api.github.com/users/jakearchibald/gists{/gist_id}","starred_url":"https://api.github.com/users/jakearchibald/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jakearchibald/subscriptions","organizations_url":"https://api.github.com/users/jakearchibald/orgs","repos_url":"https://api.github.com/users/jakearchibald/repos","events_url":"https://api.github.com/users/jakearchibald/events{/privacy}","received_events_url":"https://api.github.com/users/jakearchibald/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":20,"created_at":"2018-03-08T10:06:54Z","updated_at":"2018-03-20T19:01:43Z","closed_at":null,"author_association":"NONE","body":"Apologies if this has already been discussed to death.\r\n\r\nI'm interested in solving this case:\r\n\r\n```js\r\nimport Whatever from \"./Whatever.js\";\r\n\r\nconst whatever = new Whatever();\r\nwhatever.commonThing(123);\r\nwhatever.rareAndComplexThing(321);\r\n```\r\n\r\n…where `rareAndComplexThing` adds a lot of weight to the `Whatever` class, and should ideally be an opt-in:\r\n\r\n```js\r\nimport Whatever from \"./Whatever.js\";\r\nimport { rareAndComplexThing } from './whatever-extras.js';\r\n\r\nconst whatever = new Whatever();\r\nwhatever.commonThing(123);\r\nrareAndComplexThing(whatever, 321);\r\n```\r\n\r\nI don't really like the above. Maybe it's because it isn't clear that `rareAndComplexThing` may change the state of `whatever`.\r\n\r\nAn alternative is what RxJS did:\r\n\r\n```js\r\nimport Whatever from \"./Whatever.js\";\r\nimport \"./whatever-extras/rareAndComplexThing.js\";\r\n\r\nconst whatever = new Whatever();\r\nwhatever.commonThing(123);\r\nwhatever.rareAndComplexThing(321);\r\n```\r\n\r\nWhere `rareAndComplexThing.js` imports `Whatever.js` and adds to its prototype. But this doesn't work well with tree-shaking. RxJS's [pipable operators](https://github.com/ReactiveX/rxjs/blob/master/doc/pipeable-operators.md) fix the issue for them, but it doesn't really work for the general case.\r\n\r\nI got excited about the pipeline operator here, but now I've written it down, I'm not so sure:\r\n\r\n```js\r\nimport Whatever from \"./Whatever.js\";\r\nimport { rareAndComplexThing } from './whatever-extras.js';\r\n\r\nconst whatever = new Whatever();\r\nwhatever.commonThing(123);\r\nwhatever |> rareAndComplexThing(321); // F-sharp style\r\nwhatever |> rareAndComplexThing(■, 321); // or Hack style\r\n```\r\n\r\nWith the F-sharp style, `rareAndComplexThing` would have to be implemented like:\r\n\r\n```js\r\nexport function rareAndComplexThing(val) {\r\n  return whatever => {\r\n    // do stuff with whatever & val\r\n  }\r\n}\r\n```\r\n\r\nThat overhead isn't needed with the Hack style, but it feels really clunky. Again, it isn't clear that the state of `whatever` may be altered. I think what I really want is just:\r\n\r\n```js\r\nimport Whatever from \"./Whatever.js\";\r\nimport { rareAndComplexThing } from './whatever-extras.js';\r\n\r\nconst whatever = new Whatever();\r\nwhatever.commonThing(123);\r\nwhatever::rareAndComplexThing(321);\r\n```\r\n\r\n…where `rareAndComplexThing` is called like `rareAndComplexThing.call(whatever, 321)`. Even if pipeline ships, I think I'd rather go with:\r\n\r\n```js\r\nimport Whatever from \"./Whatever.js\";\r\nimport { rareAndComplexThing } from './whatever-extras.js';\r\n\r\nconst whatever = new Whatever();\r\nwhatever.commonThing(123);\r\nwhatever.do(rareAndComplexThing, 321);\r\n```\r\n\r\nIs the bind operator dead in favour of the pipeline operator? I like pipeline, but it doesn't feel like it solves this particular use-case. Is it intended to?"},"comment":{"url":"https://api.github.com/repos/tc39/proposal-pipeline-operator/issues/comments/374718376","html_url":"https://github.com/tc39/proposal-pipeline-operator/issues/101#issuecomment-374718376","issue_url":"https://api.github.com/repos/tc39/proposal-pipeline-operator/issues/101","id":374718376,"user":{"login":"hax","id":159840,"avatar_url":"https://avatars0.githubusercontent.com/u/159840?v=4","gravatar_id":"","url":"https://api.github.com/users/hax","html_url":"https://github.com/hax","followers_url":"https://api.github.com/users/hax/followers","following_url":"https://api.github.com/users/hax/following{/other_user}","gists_url":"https://api.github.com/users/hax/gists{/gist_id}","starred_url":"https://api.github.com/users/hax/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/hax/subscriptions","organizations_url":"https://api.github.com/users/hax/orgs","repos_url":"https://api.github.com/users/hax/repos","events_url":"https://api.github.com/users/hax/events{/privacy}","received_events_url":"https://api.github.com/users/hax/received_events","type":"User","site_admin":false},"created_at":"2018-03-20T19:01:43Z","updated_at":"2018-03-20T19:01:43Z","author_association":"NONE","body":"My comment may be *off topic*.\r\n\r\n@mAAdhaTTah \r\n\r\n> Also, IRT this, I think you are reading too far into what he said. \r\n\r\nI don't think so.\r\n\r\n> this isn't going anywhere, but its behavior can be confusing. \r\n\r\nI don't think `this` is more confusing than any other features if you *use a feature in wrong way*. Unfortunately I find some books just list all the behaviors of `this` in one place, which is totally wrong teaching method for the newcomers. \r\n\r\nEven that, I don't see much problems of confusion caused by `this` in real world. Note, there are many bugs caused by `this`, but that does not mean `this` is confusing, programmers understand `this` well, they just made mistakes. What the real problem is we are short of language features which could provide protection of such mistakes. I would like to write a proposal which might help for discover the mistakes earlier next week.\r\n\r\n> We don't want to introduce new usages that make it even more confusing, so we do have to be careful as to how we interact with it in new proposals.\r\n\r\nIt's weird to me that why we never worry about the fp style features like pipelines would be too strange to many js programmers, but consider a feature related to `this` which already in JS from the first day would be \"even more confusing\".\r\n\r\nNote, I love pipeline operators. (though some extension of smart pipelines proposal seems problematic, for example it's too easy to lose the context of what current `#` mean, maybe just the examples are not good enough, I'm not sure.) I just think we can have both world of OO and FP.\r\n"}}
{"actor":{"display_login":"hax"}}