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 can't handle custom classes #1378

Closed
ladida771 opened this issue Oct 6, 2015 · 2 comments · Fixed by #3265
Closed

merge can't handle custom classes #1378

ladida771 opened this issue Oct 6, 2015 · 2 comments · Fixed by #3265
Assignees
Milestone

Comments

@ladida771
Copy link

The result of A and B merge inherits B's custom classes which does not seem intuitive to me at all.

Example:

A=data.table(x=c(1,2,3),y=c(4,5,6))
B=data.table(x=c(1),w=c(5))
class(B) <- c("custom","data.table","data.frame")

C=merge(A,B,by=c('x'))
class(C)

Expecting: "data.table" "data.frame"
Getting: "custom" "data.table" "data.frame"

@arunsrinivasan arunsrinivasan added this to the v1.9.8 milestone Oct 6, 2015
@arunsrinivasan arunsrinivasan self-assigned this Oct 11, 2015
@michaelquinn32
Copy link
Contributor

Reopening this.

The case where the result inherits the class of B is clearly wrong. Thanks for fixing that!

But dropping the class of A is also seems incorrect to me. I think about it in terms of other OO languages. Methods usually don't change the class of the object they are called on, and I think it's a good practice to have S3 dispatch maintain the class of the object whose method is used.

IMO, this is the correct behavior:

A <- data.table(x = c(1, 2, 3), y = c(4, 5, 6))
B <- data.table(x = c(1), w = c(5))
class(A) <- c("custom", "data.table", "data.frame")
C <- merge(A, B, by = "x")
class(C)
#> "custom", "data.table", "data.frame"

Granted, merge.data.frame is breaking this rule as well, but that's a much harder thing to fix.

@jangorecki
Copy link
Member

@mattdowle not sure if we want this for 1.12.0 because it could eventually break some packages and we are already after revdeps check. I would postponed that to 1.12.2, unless there is going to be another round of revdeps checks before 1.12.0 release

@jangorecki jangorecki modified the milestones: 1.12.0, 1.12.2 Jan 10, 2019
@jangorecki jangorecki modified the milestones: 1.12.2, 1.12.4 Jan 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants