Skip to content
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

functions version with keyword arguments #251

Open
DominiqueMakowski opened this issue Sep 8, 2018 · 2 comments
Open

functions version with keyword arguments #251

DominiqueMakowski opened this issue Sep 8, 2018 · 2 comments

Comments

@DominiqueMakowski
Copy link

Now that speed issues for kwargs have solved (or reduced) with 1.0, are there any plans to add a version of the main functions (glm and lm) with keywords arguments (glm(@formula(y ~ x), data=df, family=...)?

@nalimilan
Copy link
Member

Good question. The advantage of keyword arguments would be that you don't need to remember the order of all arguments, which I agree is hard to get right. The downside would be that it's quite verbose.

Another question to address is whether all arguments should be keywords, or just some of them. For example, it would be kind of extreme to write formula=@formula(...). But why make only that exception? A possible rule could be to have the formula and data as positional arguments because they are common to all model families, while other arguments vary from one family to another (and therefore defining a standard order common to all packages isn't possible).

I must say this is one (the only?) place where I miss R's behavior where arguments can be specified either by position or by name. We could provide both a method with only positional arguments, and one with keyword arguments, but that's unusual AFAICT.

@DominiqueMakowski
Copy link
Author

I don't have enough experience with Julia to think about design decisions. I agree that positional arguments are good for experienced users, altough keyword arguments are great for their transparency and non-ambuiguity, especially for new users or people that are not used to read code.

As to what arguments to transform to kwargs, I would personally go for including data. For instance, I like writing Sepal.Length ~ Petal.length, data=iris when I teach students R because it helps explaining how things work (even if it's a bit more verbose), it makes very clear that "the data used for this model is this dataframe".

Providing both versions might be a way to make everybody happy indeed...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants