Move from private to protected for extensibility

[jom]

I'd like to extend this in my libraries. If useful and once tested, I'll add what I extend back into the library. Any harm in making things protected instead of private?

[clue]

Thanks for filing this PR!

I can see where you're coming from, but IMO making this protected is a bad choice for multiple reasons:

• It breaks encapsulation and often leads to a poor design, see e.g. http://stackoverflow.com/questions/8353272/private-vs-protected-visibility-good-practice-concern or http://fabien.potencier.org/pragmatism-over-theory-protected-vs-private.html and many, many others…
• Marking these as protected means they can and will be used in other projects, so they become part of the public API. This means we are no longer allowed to change how they work.
• I have yet to see a use case that requires protected methods that can not be accomplished with the current API

I'd like to extend this in my libraries. If useful and once tested, I'll add what I extend back into the library.

I'm really curious to see what you're up to, perhaps pushing these "extensions" upstream into this library can help finding some better extension points? 👍 Feel invited to share your finding and I'm happy to review things! :-)

[jom]

I've added a containerStats and containerLogs. I don't have tests for them yet, but can push them up, at least...

I just don't like being slowed down ;)

[clue]

I've added a containerStats and containerLogs. I don't have tests for them yet, but can push them up, at least...

Thanks for filing this in #26, I very much appreciate any suggestions, even if they're still WIP 👍

I just don't like being slowed down ;)

I agree that this process should not slow you down at all :-) File your suggestions as PRs and I'll look at these as soon as time permits. In the meantime, you can still build on top of your private fork