Woven methods lost their protected scope

[Cyrille37]

Hi

A woven protected method lost it's "protected" scope.

class TargetClass {
    public function helloWorld()
    {
    }
    protected function helloHere()
    {
    }
}
$obj = new TargetClass();
$obj->helloHere();

Without weaving it throws "Error: Call to protected method ..."

But after weaving the method became "public" so we can call it without error.

[WalterWoshid]

This, as a fact, was a choice I have made, I will add an option in the kernel to either deactive this behaviour or keep it active.

[Cyrille37]

Hello @WalterWoshid

Perhaps it's a good choice, what was your motivation for this behavior?

I don't remember if it conflicts with option "onlyPublicMethods" for "Implicit advice options: bypass trait methods, weaving only public methods" #51 ...

I just seen that when writing unit test ; it has no error while I was calling a protected method ;-)

[WalterWoshid]

Hi @Cyrille37,

good question! In my old job we used Magento 2, which is a module-based e-commerce framework for an online shop. Here we mostly bought other modules for good money and sometimes we had to adjust the logic of those modules with plugins. Those worked like AOP, but they were ugly and the biggest problem we had was that sometimes we couldn't intercept private and protected classes and I think maybe even final classes and methods. For this reason, and because sometimes a private method just NEEDS to be intercepted, I have allowed my library to do just that.

Encapsulation is a good thing, don't get me wrong, but only if it is implemented correctly, which I don't often see. For that reason I have implemented this "feature", which I will add as an option to the kernel, so that people can disable it if they want :)

Also I later want to add intercepting code structure (see issue #46) which will take it to a more extrem approach of intercepting code.