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

Merge meanings of cols keyword arguments between push! and vcat #1991

Closed
rapus95 opened this issue Oct 21, 2019 · 8 comments
Closed

Merge meanings of cols keyword arguments between push! and vcat #1991

rapus95 opened this issue Oct 21, 2019 · 8 comments

Comments

@rapus95
Copy link

rapus95 commented Oct 21, 2019

:intersect does mean different things currently

@bkamins
Copy link
Member

bkamins commented Oct 21, 2019

Agreed this should be fixed. What alternative name for what :intersect in push! does do you think is good. I think that in vcat it is an appropriate name. In push! we should not change the behavior, so we should change the name of this option.

Thank you!

@rapus95
Copy link
Author

rapus95 commented Oct 22, 2019

As :subset means that the new row needs to be at most a subset of columns. How about :superset?
Might add that to vcat aswell.

@bkamins
Copy link
Member

bkamins commented Oct 22, 2019

Yes - :superset is a good name for this!

@nalimilan nalimilan added this to the 1.0 milestone Nov 15, 2019
@bkamins
Copy link
Member

bkamins commented Dec 1, 2019

Given #1958 is merged is this still on 1.0 roadmap (I think not so I have removed the tag). The additional functionalities discussed here are non-breaking.

@bkamins bkamins removed this from the 1.0 milestone Dec 1, 2019
@rapus95
Copy link
Author

rapus95 commented Dec 2, 2019

I'll add it in the overhaul I wanted to make. As #1958 is now merged, I guess I can start working on it, can't I?

@bkamins
Copy link
Member

bkamins commented Dec 2, 2019

Yes, but I removed 1.0 milestone, as I understand your changes will be non-breaking (they will only clean up internal code or add functionality) - right?

@rapus95
Copy link
Author

rapus95 commented Dec 2, 2019

Yes, but I removed 1.0 milestone, as I understand your changes will be non-breaking (they will only clean up internal code or add functionality) - right?

Indeed, if every keyword meaning is cleaned up and consistent now and we have enough test coverage that pass, then my change will not introduce any changes to the API besides adding some new keywords. If we will add any new arguments to an API function then we'll add them by keywords, thus, that should be compatible aswell, I guess.

@bkamins
Copy link
Member

bkamins commented Dec 2, 2019

Closed in favor of #2032

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

No branches or pull requests

3 participants