Create a IsA expression

[hgraca]

This will allow for testing if a class extends or
implements another code unit, anywhere in the inheritance tree.

[jdreesen]

Do we really need to check both? Both do the same, except that is_a() also returns true for the class itself (like is_a(A::class, A::class)), AFAIK, so is_subclass_of() should never be called.

[hgraca]

unfortunately, is_a doesnt check for interface implementation, and is_subclass_of doesnt check for same class. :(

[jdreesen]

unfortunately, is_a doesn't check for interface implementation

I think it does: https://3v4l.org/91Yt8

AFAIK, is_a does the same as instanceof (and it is even more powerful, since it can check string class names and not only instances, if the third parameter is true).

[hgraca]

HAH! u r correct, I will fix this

[hgraca]

fixed and force pushed

[raffaelecarelle]

Hello, this PR is useful. When can it merge?

[micheleorselli]

Hello, this PR is useful. When can it merge?

When we used to support older php versions we wanted to avoid relying on checks triggering the autoload and parse the code statically. Not sure it still makes sense, so potentially this is a good addition. At this point I am wondering if we should just update Extend/NotExtend Implement/NotImplement. wdyt @AlessandroMinoccheri @fain182?

[hgraca]

@micheleorselli

avoid relying on checks triggering the autoload

That is why I opened this other PR but never got it merged.
This would effectively put the decision on the user; if they wanted to use an expression that would need to trigger the autoload, they would be able to, which is not the case at the moment.

That PR just adds an IF statement so we don't try to define PHPARKITECT_COMPOSER_INSTALL more than once, which triggers PHP errors.
I don't see a negative point in merging it, but if it is not desirable, let me know so I can close that PR.

[AlessandroMinoccheri]

For me, the PR is adding value.
What is your idea of extending Extend/NotExtend and Implement/NotImplement @micheleorselli ?

Maybe we can consider both ways to understand what is the correct one.

[micheleorselli]

As of now, there is a known limitation when we parse files building ClassDescription objects as we do not walk the inheritance tree, so the analisys stops at the class we currently parsing. This means that, given a ClassDescription object, the extends and implement attributes contains only classes that are directly extended or implemented.

If I have a rule saying "class X should not extend class Y" is that the expected behaviour? I doubt that 🤔

One possibile approach would be having two rules like

• Extends, which work using is_a and triggering autoload
• ExtendsDirectly which behaves like the current Extends

this also would work for implements for interfaces, use for traits, and so on

wdty? @AlessandroMinoccheri @fain182

[fain182]

When we used to support older php versions we wanted to avoid relying on checks triggering the autoload and parse the code statically.

I think we need to ensure that autoloading works with all our installation methods (Composer, PHAR, Docker); otherwise, it's a good idea. (I'm even open to deprecating some of the installation methods.)

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud