Skip to content

Conversation

@m3m0r7
Copy link
Contributor

@m3m0r7 m3m0r7 commented May 2, 2021

Support dbal v3 #1166


trait DbalTypeResolverTrait
{
protected static function resolveDbalType(string $typeName): string
Copy link
Contributor Author

@m3m0r7 m3m0r7 May 2, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method is compatible for dbal v2 and v3

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes it a requirement to include in all classes that need to use the compatibility layer between DBAL v2 & v3.

Considering that it would be a static method, there is really no need for it. It can be made a static method of a class on it's own - it does not depend on the class you want to attach it at all.

It also prevents any type of static code analysis from picking up potential errors (previously you had a well defined constant list, now you can't use that because you're depending on reflection to find class constants.

What I'd suggest instead is a "class with side effects". Normally you'd avoid creating classes that change their structure depending on the other libraries, but this would be a compatibility layer that is supposed to be adapting to DBAL version.

It would go like this:

if (class_exists(\Doctrine\DBAL\Types\Types::class)) {
    class DbalType {
        // constants defined here
    }
} else {
    class DbalType {
        // constants from the other version
    }
}

Also note that you don't need to use class name as a string. You can use the ::class notation, because using class name / type on it's own does not trigger autoloading.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Steveb-p
Thanks for your reviews. I will fix it.

using class name / type on it's own does not trigger autoloading.

I did not know its feature, Thanks. I thought it will be shown an error.

Copy link
Contributor

@Steveb-p Steveb-p May 5, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did not know its feature, Thanks. I thought it will be shown an error.

Yup. PHP is smart enough to figure out what class you're talking about (taking into account current namespace and imports) and doesn't bother with autoloading until it's actually necessary (usually when creating a new instance, calling a static method or passing it to class_exists function and it's "family").

This has the side-effect of also not triggering autoload when doing $x instanceof FooBar (FooBar is not autoloaded), and the same applies to type-hints (even method arguments / property types!). In 99.9% of cases it's not relevant, as at some point you had to have an instance somewhere before (so the class is loaded). This becomes an issue (that 0.01% 😄 ) when you're using class_alias, but that's really a special case.

See https://www.schmengler-se.de/en/2016/09/php-using-class_alias-to-maintain-bc-while-move-rename-classes/

Copy link
Contributor Author

@m3m0r7 m3m0r7 May 12, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the late commit 🙏 I did fix it.
I'm thinking that do not necessary to use the if statement when creating a new class and copy&paste from the dbal source.
Therefore, I wrote only one class.

@makasim makasim merged commit 29584b1 into php-enqueue:master Jun 4, 2021
@m3m0r7 m3m0r7 deleted the support-dbalv3 branch June 6, 2021 02:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants