Replies: 2 comments
-
Hi @gilou. I agree that this is a restrictive change. There were a lot of internal reasons for it. Currently, our internal implementation for partial application was adding a lot of complexity and, from a developer perspective, the benefits were non-negligible so we went with it. I can leave it to @smimram to talk more about it but I believe that if we can devise a better implementation, we'd be more than happy to bring it back. |
Beta Was this translation helpful? Give feedback.
-
As for naming, Same thing goes with |
Beta Was this translation helpful? Give feedback.
-
Hi,
Just wanted to vent. I’m finally migrating what I hadn’t finished on 2.x when 2.0 came out... And I had 2 issues that... still haunt me, so maybe some will benefit from the info.
Partial function. No thank you for removing them. Docs for migration says:
(from our experience it was not used much anyway).
.It was, and heavily, especially for dynamic, massive setups that required the same thing set up with runtime differences (usually an external identifier, or a structure to log data). And... for callbacks... on_track(my_shortcut(x)) with my_shortcut being a much more complex function with "default" parameters... I had dozens of them, and I had to all rewrite them as fun(param) -> complex(default, default, default, param).. not fun.
Also, doc could include a word about named parameters in fun(~x), given how angry I was at this, it took me 20 minutes to figure out why my fake partial function would not accept my params... Totally logical, but very much annoying.
Last thing... Now we got a lot of functions through source.xxx() which are really helpful, and make more sense... However, source did not use to be a reserved word, and... guess what... I had many places using source = xxx as a boilerplate starter for complex scripts. Not fun. Not an actual issue either....
Beta Was this translation helpful? Give feedback.
All reactions