-
Notifications
You must be signed in to change notification settings - Fork 3k
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
Switch to config objects for operators with a lot of arguments. #3515
Comments
Hi @benlesh! If this is still a thing I would create a list of all the operators that have enough arguments to get refactored to a config object. I would collect:
I would provide it as markdown like this:
Let me know if the suggested approach would be helpful or if I can adapt anything. |
Thanks @BioPhoton.... we probably don't even need that level of detail. Just a list of the operators that have 3 or more arguments would be a great start. |
Could you suggest a naming pattern? |
Hi @benlesh! Here the list of operators/functions that have 3 or more arguments (n means infinite) Subjects
Creation Methode
Operators
|
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
There are a few operators that have a lot of arguments, one example would be
groupBy
. This hurts readability a bit and also bites us later if we want to change or deprecate arguments.So the idea is simple, introduce non-breaking changes to operators like
groupBy
to allow the passing of a config object to essentially provide "named arguments":(The names can be bikeshedded later, ideally to make it more terse but still readable)
The text was updated successfully, but these errors were encountered: