-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
RFC: deprecate AbstractPlatform::getName() #4749
Comments
I still like |
If I have to support multiple versions of DBAL, I would need to check for multiple base classes in order to detect a specific database engine. For instance, on DBAL 2.13, there is |
Oh so the possible values of It might feel better to have a list of supported families defined as constants in an enum-like class looking like <?php
declare(strict_types=1);
namespace Doctrine\DBAL\Platforms;
final class PlatformFamily
{
public const POSTGRESQL = 'postgresql';
// …
/**
* @codeCoverageIgnore
*/
private function __construct()
{
}
} WDYT? |
I don't see a big problem with magic strings here, but sure, having an enum might be helpful. |
Yes, it's been for a long time on my mind, just didn't ever get to it. We got rid of most of other |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
I should have asked when reviewing https://github.com/doctrine/orm/pull/8870/files#diff-3e426fe47b58d2d4b970b1b7a0cbf5999af950e4f84e48dce4bee5061b57ed31R657 (cc @derrabus ), but what good is a
getName()
method when you can useinstanceof
? Isn't it more fragile?In the past I remember Symfony deprecating form names, and recommending avoidance of services IDs that are not FQCN, and IMO this has makes things more clear. Should we get rid of
AbstractPlatform::getName()
as well?The text was updated successfully, but these errors were encountered: