Change visibility of handler classes to protected

[PillFall]

Some properties and methods of the handler classes are set to private and some others to protected.

I change the visibility of all of them to protected. I believe this is a better practice, as it allows us to extend the handler.

If there are any security concerns of why this is the way it is, please do let me know.

Example

The MongoDBHandler stores the configuration private as shown:

monolog/src/Monolog/Handler/MongoDBHandler.php

Lines 37 to 41 in d97d5e9

	private \MongoDB\Collection $collection;
	private Client|Manager $manager;
	private string|null $namespace = null;

But the DynamoDBHandler stores the configuration protected as shown:

monolog/src/Monolog/Handler/DynamoDbHandler.php

Lines 32 to 36 in d97d5e9

	protected DynamoDbClient $client;
	protected string $table;
	protected Marshaler $marshaler;

With how is the code right now, I can extend the DynamoDbHandler to add querying functionality, all without having to create a new configuration object (aka Aws\DynamoDb\DynamoDbClient).

But with MongoDBHandler, I have to redo the argument parsing in its construct function to include this functionality, creating also two copies of the same exact object in memory (aka MongoDB\Driver\Manager or \MongoDB\Collection).

[Seldaek]

Thanks for the PR, however I do not think this is a good change as it makes refactoring much harder as the API surface becomes much larger.

We do accept PRs to open up properties/methods to be overridden/extended whenever someone has a valid use case though.

[PillFall]

I do not think this is a good change as it makes refactoring much harder as the API surface becomes much larger.

@Seldaek can you explain this for me?

I don't get why this change will make refactoring harder, this PR will only change a private w/o extension to a private w/ extension.

The same properties and methods will be available in a similar fashion, but allowing users to further extend the API, there are zero noticeable changes for the user.

Also, this seems like a wanted feature and a main concern for users as this is a blocker for many projects.

See for example #1866, #1875, #1912, and so many others.

[Seldaek]

Right now we get PRs to mark stuff protected when there's a use case for it. So we can discuss use cases, prevent some people from making mistakes, learn how people use it, etc.

If we mark it all protected, no method or property can be changed/refactored anymore without the chance of BC break. In terms of public API surface everything protected is part of the public API, and potentially used by someone somewhere.

I hope this helps clarify my view

[stof]

@PillFall protected properties are covered by the backward compatibility requirements of semver (and properties are harder to handle than methods regarding compatibility layers when property hooks are not an option). Protected properties are closer to public ones than to private ones in term of impact on maintenance.