Skip to content
This repository has been archived by the owner on Aug 30, 2019. It is now read-only.

writer: make internal identifiers private #504

Merged
merged 4 commits into from
Oct 25, 2018
Merged

Conversation

gbbr
Copy link
Contributor

@gbbr gbbr commented Oct 24, 2018

  • Makes internal writer identifiers private
  • Absorbs BasePayloadSender into QueuablePayloadSender
  • Renames QueuablePayloadSender to queuableSender.

@gbbr gbbr added this to the 6.7.0 milestone Oct 24, 2018
@gbbr gbbr requested a review from AlexJF October 24, 2018 10:55
Copy link

@AlexJF AlexJF left a comment

Choose a reason for hiding this comment

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

Just something that crossed my mind while reviewing this.

@@ -163,7 +163,7 @@ func (m *mockPayloadSender) Reset() {
m.mu.Unlock()
}

func (m *mockPayloadSender) Start() {
func (m *mockPayloadSender) start() {
Copy link

Choose a reason for hiding this comment

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

Does it make sense to turn every method private? That way when using this class inside the writer package, it's not evident what constitutes the "public" interface of a sender vs what are internal helper methods. Perhaps it's sufficient to set the structs/interfaces themselves as private?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

As far as I know we should only export identifiers used in other packages. I don't think there is a concept of private and public at a structure level in Go. Even though I like your idea, and I did understand from the start that this was your intention, I'm not sure if it'll give the same impression to others too. I don't feel strongly about it and I could revert that part of the change if you wish, but I'd say it's not needed.

Additionally, I plan on coming back here and investigating a better way to test (e.g. by removing the syncBarrier and also the interfaces). I think you've initially added the interface only to facilitate testing and I think there might could be a simpler way.

I'll leave this decision up to you. I don't mind reverting if you feel it would make things clearer. But keep in mind that setEndpoint is the only method that is causing the confusion and I plan on removing it (it is only there to help with tests). After that work is done there will be no more confusion between actual methods and test helper methods.

Copy link

@AlexJF AlexJF left a comment

Choose a reason for hiding this comment

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

I'd prefer reverting because for example, the only safe methods for users of queueableSender are Start, Run, Stop, Send, NumQueuedPayloads and Monitor. If we put everything as lowercase, users might be tempted to use enqueue, sendOrQueue, flushQueue and others which were not coded with external calls in mind (lacking thread safety, etc...).

@gbbr
Copy link
Contributor Author

gbbr commented Oct 25, 2018

Ah, ok. I see what you mean now. I was looking at it only through the interface's methods, not through the entire structure.

@gbbr
Copy link
Contributor Author

gbbr commented Oct 25, 2018

Done 👍

// Write writes the payload to the endpoint.
Write(payload *Payload) error
write(payload *payload) error
Copy link

Choose a reason for hiding this comment

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

As a matter of consistency we should strive for this uppercase public interface methods everywhere, what do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I wouldn't want to enforce that. I get the logic in the sender because of setEndpoint which is specifically there for tests, but I wouldn't want to make this a rule. If we capitalise these, it means that technically they can be accessed from outside the package too if this interface would be returned anywhere.

Copy link

@AlexJF AlexJF left a comment

Choose a reason for hiding this comment

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

As commented offline, I think internal packages are really the way to go here so we can keep both the public and package-level interfaces clean. I do agree this is a bigger revamp so I'm fine with doing this in a separate PR.

@gbbr
Copy link
Contributor Author

gbbr commented Oct 25, 2018

Thanks for helping out. Indeed internal is what's needed here.

@gbbr gbbr merged commit ae5474e into master Oct 25, 2018
@gbbr gbbr deleted the gbbr/merge-payload-senders branch October 25, 2018 09:55
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants