puppet-php icon indicating copy to clipboard operation
puppet-php copied to clipboard

Remove "private class" checks

Open tobru opened this issue 9 years ago • 3 comments

In my personal opinion it doesn't make sense that classes check if the were called from the same module. I'm speaking of checks like this: if $caller_module_name != $module_name. I'd like to remove this checks to make the module more flexible. If there are no strong reasons to leave this there, I'm happy to create a PR.

tobru avatar Dec 21 '15 16:12 tobru

I think it is important to make a difference between "public" classes and "private" ones. Puppet does not support a better way to enforce encapulation here.

For the maintainers, it might be important to know which parameters may be changed (renamed, moved to other internal classes) and whihc must be kept as part of the module API.

mpdude avatar Dec 21 '15 16:12 mpdude

Yes of course, but if I want to use a "private" class directly, f.e. because the main class does not allow to configure all parameters of a private class, or I have other ideas to use a private class directly, then it's annoying when there are a lot of red warnings. If I use a private class directly, then I'm also aware of the fact that parameters could change which then is my own responsibility to fix my class. Maybe put a notice in the class documentation which says that this class could change parameters from time to time...? And mention it in the changelog if they change?

The only way of making the usage of a private class not needed is when all parameters would be exposed to the main class, but that misses a bit the point of a private class.

It would make this module much more user friendly without this private class enforcement, I could call the classes from outside like it fits my needs. And I think flexibility is very important for a "base" module like this one.

tobru avatar Dec 21 '15 17:12 tobru

We wrote this module with hiera usage in mind. The idea is to only include the main class and configure the rest with hiera. Clearly, seeing many issues on that topic, people prefer to mix data and code and I agree that we shouldn't stand in the way here.

Not that there is some imported logic and dependency management happening in init.pp that you would have to replicate currently. That's why most sub-classes are marked as private. Fixing this is probably a major refactoring which we are not able to do right now due to time constraints.

Pull requests are welcome.

fpletz avatar Mar 23 '16 23:03 fpletz