-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
To use a more intuitive and straightforward name/alias #94
Comments
Hi, we had an internal vote regarding changing the name among the maintainers and the results are:
Seriously though, I am definitely for the change. Also since readability is the main concern, we should definitely deprecate One additional improvement we can make here is to make the API consistent with |
I have an idea for a slightly different naming scheme:
What do you think? @baldram |
Hi Kacper, thank you for your response. I'll respond sequentially to both answers.
😄
To be honest, I would save effort here. If there are too many ways to use the library, it will become difficult to understand. It's better to stick to one good and well-thought-out option. And if someone is migrating from the Kit's library, it's just one batch replace in the entire project, and the name can be changed. Please see a discussion here: kitlangton/parallel-for#8
How about Thanks to the documentation and code completion, someone can find the "unordered" variant, which from the Scaladoc description will have the necessary information that it's a more aggressive version. The basic one, without an additional suffix, can be simply named, and additionally, Scaladoc will explain what this variant does and refer to the second option if someone wants to achieve something more. I'm not sure if we want to use "pointlessly terse" abbreviations. Those few characters won't save much, and it's still the beginning of a code block; there won't be anything else on that line. A simple and self-explanatory name will make it so that someone seeing such code will immediately understand what's happening, even if they encounter Avocado for the first time in their life. What do you think? PS: Were you at Scalar this year? The leitmotif was "Lean Scala". Let's demystify Scala, let's not complicate it unnecessarily. Scala for people ;) |
This all seems like much ado about nothing. ... Just kidding. I only wanted to make that pun. UPDATE: Oops. And now I hit enter too early. I'm for the somewhat more verbose/clear variant! I'm all in for parallel/parallelize 😛 |
Hello Dear Maintainers, thank you for your work on this incredibly useful library!
I would like to propose an improvement in order to use a more intuitive name that directly relates to the functionality that the library provides.
I understand the origin of the name and its references to Haskell. However, from the perspective of Scala, not everyone has such roots, and without additional explanations, the name
ado
doesn't say much. A new person in the project, seeing something like this in the code, may feel lost. Seeing the wordparallel
orparallelize
, they will easily understand what a given code block does.If this is a good idea and is well received, creating an alias would likely be a solution, providing backward compatibility. Taking it a step further, standardising and adding the
@deprecated
annotation toado
would be an additional option to consider.I would also refer to @szymon-rd's presentation from Scalar 2023, which teaches us that we may want our code to be easier to read and libraries designed to be intuitive:
https://www.youtube.com/watch?v=nA9gRGpOOJc
Finally, an example for applicative-for would look like that (using
parallel
,parallelize
, or similar).What do you think?
The text was updated successfully, but these errors were encountered: