Skip to content
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

Incorrect class path for property when using traits #2467

Open
danaki opened this issue Jul 3, 2020 · 6 comments
Open

Incorrect class path for property when using traits #2467

danaki opened this issue Jul 3, 2020 · 6 comments

Comments

@danaki
Copy link

danaki commented Jul 3, 2020

When class A uses trait B and that trait defines a property like so:

namespace App\Entity;

use App\Entity\Enum\CommissionType;

trait ContractTrait
{
    /**
     * @var CommissionType
     */
    protected $commissionType;
}

then $commissionType resolved as App\Entity\CommissionType not \App\Entity\Enum\CommissionType (please refer to src/bug.php from the repository reproducing bug: https://github.com/danaki/phpdocumentor-bug

Run:

composer install
php src/bug.php

Output:
\App\Entity\CommissionType

Should be:
\App\Entity\Enum\CommissionType

Versions of phpDocumentor components are fixed to required by Symfony 5 and latest API Platform. May be this bug already fixed in recent releases of phpDocumentor then API Platform should be upgraded.

@jaapio jaapio added this to Needs triage in phpDoc issue triage board Jul 3, 2020
@jaapio
Copy link
Member

jaapio commented Jul 3, 2020

Hi @danaki,

This is a known issue. The problem here is that php's reflection library doesn't provide the information. It is kind of hard to solve this without much performance impact. The issue is tracked in the type-resolver component which should cover these use cases. But we still don't know exactly how.

phpDocumentor/TypeResolver#82

Thanks for reaching out. And providing so much information to reproduce this issue.

@danaki
Copy link
Author

danaki commented Jul 5, 2020

I think performance doesn't matter because reflection can't be fast per se. Can you please at least make it throw an exception if you can't fix it right now because this behavior leads to erroneous situation. I've spent hours debugging API Platform/Symfony internals to find out this bug belongs to phpdocumentor without knowing this project even exists.

@jaapio
Copy link
Member

jaapio commented Jul 5, 2020

The problem with throwing an exception is that we don't know at runtime that your trait exists, if we would know it, we could have returned the correct type.

I'm sorry to hear that you had to spend so much time on this. Since we had contact with both the Symfony team and the API platform team about this particular issue, they should have mentioned this in their docs. You might want to open an issue for that :-)

@danaki
Copy link
Author

danaki commented Jul 5, 2020

Is there a chance php core developers will fix this reflection issue in an upcoming release? Are they aware?

@jaapio
Copy link
Member

jaapio commented Jul 6, 2020

I don't know if the core developers are aware. If they are it would probably not be a minor fix. Because of way that traits work. I don't know if they do exist at runtime. Sometimes php has its limits. Thing you just run into one. Traits are dark magic, also in the core. As far as I know. Pretty useful for developers, but they don't have a meaning at runtime.

@mvriel
Copy link
Member

mvriel commented Jul 6, 2020

IIRC, traits are literally automated copy-paste. From what I understand, upon interpreting a class the contents of a trait are copy-pasted into that class and all references to that trait are gone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
phpDoc issue triage board
  
Needs triage
Development

No branches or pull requests

3 participants