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

Aliased methods imported from a trait misidentify themselves by their original name during call interception #5

Closed
antecedent opened this Issue Dec 22, 2012 · 2 comments

Comments

Projects
None yet
1 participant
@antecedent
Owner

antecedent commented Dec 22, 2012

Let's say we have a trait with a single method:

trait FooSayingTrait
{
    static function speak()
    {
        echo "foo";
    }
}

This trait is used by a class, importing the trait's method under a different name. The original name of the imported method is taken by a new method:

class Babbler
{
    use FooSayingTrait {
        speak as sayFoo;
    }

    static function speak()
    {
        echo "bar";
    }
}

Now attempting to redefine the sayFoo method, imported from FooSayingTrait, will fail, albeit without producing any errors:

Patchwork\replace("Babbler::sayFoo", function() {
    echo "spam";
});

Babbler::sayFoo(); # prints "foo", not "spam" as one would expect

This happens because everytime Babbler::sayFoo is called, it identifies itself with Patchwork by its original name, that is, Babbler::speak. Since there aren't yet any patches for Babbler::speak, the original implementation of this method runs. (For the actual call interception code that Patchwork makes run on every call to a user-defined function, see CALL_INTERCEPTION_CODE.)

This is supported by the fact that trying to redefine Babbler::speak will redefine Babbler::sayFoo as well:

Patchwork\replace("Babbler::speak", function() {
    echo "eggs";
});

Babbler::speak(); # prints "eggs"
Babbler::sayFoo(); # prints "eggs", not "foo" or "spam" as it should
@antecedent

This comment has been minimized.

Show comment
Hide comment
@antecedent

antecedent Dec 22, 2012

Owner

Sadly, I'm unlikely to fix this by myself anytime soon due to serious health issues that I've also mentioned here.

Owner

antecedent commented Dec 22, 2012

Sadly, I'm unlikely to fix this by myself anytime soon due to serious health issues that I've also mentioned here.

@antecedent

This comment has been minimized.

Show comment
Hide comment
@antecedent

antecedent Dec 24, 2012

Owner

Nevermind — this is now fixed in version 1.2.0.

Owner

antecedent commented Dec 24, 2012

Nevermind — this is now fixed in version 1.2.0.

@antecedent antecedent closed this Dec 24, 2012

@antecedent antecedent reopened this Dec 25, 2012

@antecedent antecedent closed this Dec 26, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment