-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Remove internal from comparator-related classes constructor #7038
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: 4.3.x
Are you sure you want to change the base?
Conversation
@morozov: Do we want userland code to create custom Comparator implementations? If so, the constructor indeed should not be |
Most of the DBAL code that can be extended wasn't designed with maintainability in mind. The only extensible and maintainable API I can think of is the drivers. I deliberately marked the Comparator constructors as as internal to allow us adding required parameters to the constructor without breaking the API. Personally, I'd say that as long as extending those classes works, advanced users can do that and accept the risks of breaking changes. |
I don't see the real benefit when dbal/src/Schema/AbstractSchemaManager.php Lines 997 to 1000 in 54d70d8
If you add a required parameter in the Comparator constructor, you'll still need to provide a default value in createComparator definition... Also after 4 years, it could be considered that the constructor is mature enough to provide BC. |
In this case,
The same argument could be reversed. You can rely on the API w/o an explicit BC promise because you need that and it's been stable enough. |
With this "reversed" argument, you could add My main issue is the fact that you cannot promise the BC policy is a important blocker to write/expose an open source library then since I cannot be fully sure it won't break one day with a patch/minor bump (and I won't control such bump when requiring something like DBAL
I understand it wasn't design this way at first. But is it a big deal to offer extensibility now ? |
Honestly, this might be the right thing to do. Alternatively, we could document that public API with I don't want to declare these internal APIs as public because they are not. It's as simple as that. |
but when we're writing an own custom schemaManager, extending AbstractSchemaManager, we'll need still need a way with BC to instantiate a Comparator in order to implement/override the
createComparator
method.When writing our custom Comparator, we should be able to implements
compareSchemas
orcompareTable
so we need a way with BC to instantiate a SchemaDiff/TableDiff/ColumnDiff classes (It doesn't forbid those class to be final @morozov)Another reason to allows instantiate a SchemaDiff/TableDiff/ColumnDiff classes is to write tests when implementing our own Platform and we want to unit tests the methods
getAlterSchemaSQL
orgetAlterTableSQL
.