{"action":"created","issue":{"url":"https://api.github.com/repos/numeract/rflow/issues/1","repository_url":"https://api.github.com/repos/numeract/rflow","labels_url":"https://api.github.com/repos/numeract/rflow/issues/1/labels{/name}","comments_url":"https://api.github.com/repos/numeract/rflow/issues/1/comments","events_url":"https://api.github.com/repos/numeract/rflow/issues/1/events","html_url":"https://github.com/numeract/rflow/issues/1","id":305551981,"number":1,"title":"open list","user":{"login":"MikeBadescu","id":6641575,"avatar_url":"https://avatars2.githubusercontent.com/u/6641575?v=4","gravatar_id":"","url":"https://api.github.com/users/MikeBadescu","html_url":"https://github.com/MikeBadescu","followers_url":"https://api.github.com/users/MikeBadescu/followers","following_url":"https://api.github.com/users/MikeBadescu/following{/other_user}","gists_url":"https://api.github.com/users/MikeBadescu/gists{/gist_id}","starred_url":"https://api.github.com/users/MikeBadescu/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/MikeBadescu/subscriptions","organizations_url":"https://api.github.com/users/MikeBadescu/orgs","repos_url":"https://api.github.com/users/MikeBadescu/repos","events_url":"https://api.github.com/users/MikeBadescu/events{/privacy}","received_events_url":"https://api.github.com/users/MikeBadescu/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2018-03-15T13:27:20Z","updated_at":"2018-05-05T16:03:15Z","closed_at":null,"author_association":"OWNER","body":"Open list / wishes / references. Once fully defined, move them to separate issues"},"comment":{"url":"https://api.github.com/repos/numeract/rflow/issues/comments/386815655","html_url":"https://github.com/numeract/rflow/issues/1#issuecomment-386815655","issue_url":"https://api.github.com/repos/numeract/rflow/issues/1","id":386815655,"user":{"login":"MikeBadescu","id":6641575,"avatar_url":"https://avatars2.githubusercontent.com/u/6641575?v=4","gravatar_id":"","url":"https://api.github.com/users/MikeBadescu","html_url":"https://github.com/MikeBadescu","followers_url":"https://api.github.com/users/MikeBadescu/followers","following_url":"https://api.github.com/users/MikeBadescu/following{/other_user}","gists_url":"https://api.github.com/users/MikeBadescu/gists{/gist_id}","starred_url":"https://api.github.com/users/MikeBadescu/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/MikeBadescu/subscriptions","organizations_url":"https://api.github.com/users/MikeBadescu/orgs","repos_url":"https://api.github.com/users/MikeBadescu/repos","events_url":"https://api.github.com/users/MikeBadescu/events{/privacy}","received_events_url":"https://api.github.com/users/MikeBadescu/received_events","type":"User","site_admin":false},"created_at":"2018-05-05T16:03:15Z","updated_at":"2018-05-05T16:03:15Z","author_association":"OWNER","body":"Notes:\r\n- writing an wrapping (`_rf`) function for each function is annoying\r\n- the most important option in the wrapping function is the `eddy` ==> option to set a default eddy\r\n- consider an special operator, e.g. `%rflow%` (similar to `%>%` and `%dopar%`) that provides the caching\r\n```\r\nf1(a, b) %rflow%\r\nf2(c) %rflow%\r\nrf(f3(d), rflow_options = ...)\r\n```\r\n- details:\r\n    + the first `%rflow%` does `f1(a,b) %>% f2(c)` while recognizing f1 and f2 as functions, adding them to the eddy and inspecting their arguments; it also can identify whether each input is already an rflow\r\n    + the second `%rflow%` takes the first input (an rflow now) and performs `%>% f3(d)`; it recognizes `rf()` function as a special function that provides additional options to the f3's rflow.\r\n- we cannot have `f1 %rflow% f2 %rflow% rf(options...)` since `rf()` will be parsed after`f1 %rflow% f2` and it is confusing w.r.t. the order of operations\r\n    + maybe `f1 %rflow% rf(options...) %rflow% f2` could work under the convention that `rf` always applies to the next argument, e.g. (`f2`), \r\n    + thus, in this case, `rf` does not apply to `f1` and it is \"preserved\" within the rflow of `f1` to be passed to `f2` \r\n    + but it is still confusing and goes against the standard `%>%` logic\r\n    + maybe setting options to the \"downstream / outward\" rflow using `with_rf(...)` or `set_rf(...)` ==> implies it applies downstream (to all downstream or just to the next?)\r\n- by default (without `%rflow%`), `rf` does nothing, it is the `identity` function\r\n    + changing the pipe op to `%>%` gives the standard pipe\r\n    + maybe an option for the `%rflow%` op to behave like `%>%` for debug purposes?\r\n- not keen to store these settings in `options`\r\n    + maybe store them in a package env ?\r\n    + or set them at the beginning of each pipeline? e.g., `with_rf(options) %rflow% ...`\r\n- better op name:(?) `%>rf>%`, `%rf%`, `%rf>%`; `%rf>T%` for the T op?\r\n"}}
{"actor":{"display_login":"MikeBadescu"}}