Embrace extendability and make all private Transport methods protected

[mfn]

Summary

While trying to fix #32 locally
by overriding the send() method, I realized I couldn't do this because send()
calls private methods I can't access.

Since the class already contains a mix of protected/private/public, I suggest to
make everything "protected by default".

For a read on the philosophy on this, I would like to suggest to read
http://fabien.potencier.org/pragmatism-over-theory-protected-vs-private.html
for inspiration.

[vladsandu]

@mfn thank you for sharing that. It was a good read.

I'm generally a bit torn in regards to this philosophy, but I agree that for this particular library, it would be a good fit and the added extensibility would be valuable.

I will be including this in the next release, which I'll be doing later today.

[mfn]

I'm generally a bit torn in regards to this philosophy

I can understand and if I may be honest, it took me some time to digest and formalize my mind regarding this.

In any non-OSS codebase I worked on, there's basically only public or private; rarely protected (only when actual inheritance is relevant).

But what I've seen over the last half decade of contribution in the OSS world is this:

• more people were helped with in that that they had the flexibility to override protected methods
  vs
• the minority of people which were hit by backwards incompatible changes because non-documented internal methods did change unexpectedly, even in minor versions

Ultimately making it protected kind of makes part of the contract of users of the library and does increase the complexity of handling compatibility / releases / adherence to semver.

---

On a higher philosophical level, the "Open" in "Open Source Software" does in way for me reflect this "openness" also in actual code. I don't think I'll ever write private in library code again.

Thanks for merging!

[vladsandu]

Thank you for sharing your experience on this! Those are definitely some valid points that you're making.