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

Favor the function over the method syntax when cloning a reference counted pointer. #1037

Merged
merged 3 commits into from
Apr 3, 2017

Conversation

nical
Copy link
Contributor

@nical nical commented Mar 30, 2017

data.clone() reads like performance hazard, due to the vague definition of Clone, which can be either very expensive if data is an uniquely owned large resource or very cheap if it is a reference counted pointer to such a resource. This has already confused people reading the code and even code reviews several times in webrender, so I would like to work around this unfortunate ambiguity.

I first tried to address this at the standard library level but the decision of the rust team appears to be that we should use the function syntax instead of the method syntax to address the problem.

See also the clippy issue about providing a lint for this.

I decided to take a systematic approach and use the function call syntax for all of the outstanding reference counted pointer clones that I came across (I would not be surprised that I missed some of them). Rather than try to separate the obvious from the ambiguous ones. I would rather make this a default policy than have to debate about where the line is in each code review.

The three commits are independent and can be reviewed separately (although they are small and simple enough to look at as one diff if you prefer).


This change is Reviewable

@nical
Copy link
Contributor Author

nical commented Mar 30, 2017

r? @kvark

@@ -709,7 +709,7 @@ impl ResourceCache {
is_opaque: image_descriptor.is_opaque,
}
} else {
image_template.descriptor.clone()
image_template.descriptor
Copy link
Contributor

@nox nox Mar 30, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change is not related to what the PR describes, please remove or put in its own commit.

Copy link
Member

@kvark kvark Mar 30, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nox I think you are overly sensitive here. It doesn't appear to me that the change bears any danger, and it's a bit related to the clone() refactor.

@kvark
Copy link
Member

kvark commented Mar 30, 2017

@nical I see where you are coming from, and the change looks clean.
However, I'm not yet convinced that this is the way to go for all Rust libraries. The RFC discussion basically concluded that if you want it, you are free to use it, and the clippy issue discussion is empty so far (I know, the issue is recent). I'd like to get some opinion from @glennw and Rust Core team.

@bors-servo
Copy link
Contributor

☔ The latest upstream changes (presumably #997) made this pull request unmergeable. Please resolve the merge conflicts.

@glennw
Copy link
Member

glennw commented Mar 30, 2017

I really like this idea.

@nical
Copy link
Contributor Author

nical commented Mar 30, 2017

I did a last rebase before I disappear for 2 weeks. Don't hesitate to re-submit this in my place if a consensus is approached while I'm away.
I really think we would benefit from favoring this syntax. The rust core team decided stand on the side of letting people use the function syntax if they want to. Whether we want to hand pick places where we use it or apply it consistently is really up to us. Clippy support would be a plus but doesn't affect whether this style is to be considered good or bad for us.

@kvark
Copy link
Member

kvark commented Apr 3, 2017

I'm not going to block this. @glennw please proceed if you are happy about it.

@glennw
Copy link
Member

glennw commented Apr 3, 2017

OK, let's merge it. We can always change back if we decide it's not worthwhile. Thanks!

@glennw
Copy link
Member

glennw commented Apr 3, 2017

@bors-servo r+

@bors-servo
Copy link
Contributor

📌 Commit 45a2fa8 has been approved by glennw

@bors-servo
Copy link
Contributor

⌛ Testing commit 45a2fa8 with merge 0d4041b...

bors-servo pushed a commit that referenced this pull request Apr 3, 2017
Favor the function over the method syntax when cloning a reference counted pointer.

```data.clone()``` reads like performance hazard, due to the vague definition of Clone, which can be either very expensive if data is an uniquely owned large resource or very cheap if it is a reference counted pointer to such a resource. This has already confused people reading the code and even code reviews several times in webrender, so I would like to work around this unfortunate ambiguity.

I first tried to address this at the [standard library level](rust-lang/rfcs#1954) but the decision of the rust team appears to be that we should use the function syntax instead of the method syntax to address the problem.

See also the [clippy issue](https://github.com/Manishearth/rust-clippy/issues/1645) about providing a lint for this.

I decided to take a systematic approach and use the function call syntax for all of the outstanding reference counted pointer clones that I came across (I would not be surprised that I missed some of them). Rather than try to separate the obvious from the ambiguous ones. I would rather make this a default policy than have to debate about where the line is in each code review.

The three commits are independent and can be reviewed separately (although they are small and simple enough to look at as one diff if you prefer).

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/webrender/1037)
<!-- Reviewable:end -->
@bors-servo
Copy link
Contributor

☀️ Test successful - status-travis
Approved by: glennw
Pushing 0d4041b to master...

@bors-servo bors-servo merged commit 45a2fa8 into servo:master Apr 3, 2017
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

Successfully merging this pull request may close these issues.

5 participants