Make names of Sender<> and Receiver<> variables more coherent#29710
Make names of Sender<> and Receiver<> variables more coherent#29710bors-servo merged 1 commit intomasterfrom
Conversation
mrobinson
left a comment
There was a problem hiding this comment.
This is a great start. I think in cases where a sender is merely used to send a response, we shouldn't use the name of the data type that is sent over it, but describe its purpose ie response_sender. I understand that this is an annoying change to make so I'm happy to do that if it's too tedious.
Thank you for the review :) I have tried to accumulate these changes in recent commit. |
c4ba6eb to
9f4fd0d
Compare
9f4fd0d to
55de8e3
Compare
|
@bors-servo r+ Thank you. I've made a couple small change and squashed the commits. |
|
📌 Commit 55de8e3 has been approved by |
|
@bors-servo retry |
|
@atbrakhi: 🔑 Insufficient privileges: not in try users |
|
bors is working the way through the merge queue, so it might take a little while before it gets to this change. |
|
Test results for linux-wpt-layout-2013 from try job (#4913697960): Flaky unexpected result (19)
Stable unexpected results that are known to be intermittent (15)
|
|
☀️ Test successful - checks-github |
Sometimes these variables are called port, sometimes ipc, sometimes they have the name of the thread on the other end and sometimes not. This PR tries to standardize on an obvious name for all of them:
Common pattern to note in this PR:
IpcSender, then naming is followed byipc_sender, such as:bluetooth_ipc_sender,canvas_ipc_senderetc..crossbeam_channelsender/receiver then naming is followed bysender/receiversuch as:devtools_sender,canvas_senderetc..../mach build -ddoes not report any errors./mach test-tidydoes not report any errors