Skip to content

resolvePartialStructuralElementName gives wrong namespace #82

Open

Description

@webmake

Hello, I have 2 classes in different namespaces, and trait connecting them, ex:

namespace Command\Common\Traits;

use Command\Model\Payment\UserAccountDetails;

trait UserDetailsAwareTrait
{
    /**
     * @var UserAccountDetails
     */
    protected $userAccountDetails;

    public function getUserAccountDetails(): UserAccountDetails
    {
        return $this->userAccountDetails;
    }

    public function setUserAccountDetails(UserAccountDetails $userAccountDetails): void
    {
        $this->userAccountDetails = $userAccountDetails;
    }
}
namespace Command\Bank;

use Command\Common\Traits\UserDetailsAwareTrait;
use Command\Model\Payment\UserData;
use Money\Money;
use Ramsey\Uuid\UuidInterface;

class DepositCommand
{
    use UserDetailsAwareTrait;
}
namespace Command\Model\Payment;

class UserAccountDetails
{
    /**
     * @var bool|null
     */
    private $accountVerified;

    public function isAccountVerified(): ?bool
    {
        return $this->accountVerified;
    }

    public function setAccountVerified(?bool $accountVerified): UserAccountDetails
    {
        $this->accountVerified = $accountVerified;

        return $this;
    }
}

And logic failure occurs in resolvePartialStructuralElementName.

$context variable content:
image
and $type = "UserAccountDetails".

So it cannot be just simple $namespace . $type, I guess it should check within trait namespace of UserAccountDetails, but I don't know where it cames from.

It seems that another library have already resolved this issue, you can take a look and this one

Maybe $context should include UserDetailsAwareTrait trait uses, so it would be resolved as $namespaceAliases[$typeParts[0]]

Activity

  1. jaapio commented on Apr 27, 2020

    @jaapio
    Member

    The problem here is that we are using php's reflection component to get the location of the property. At runtime the traits do not exist anymore so we cannot resolve this correctly without a lot of overhead.

    I investigated this issue earlier but forgot to respond here.
    There might be a way to get it working correctly but we need to benchmark this to see what the impact will be and to see if this is acceptable for us.

  2. self-assigned this
    on Apr 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions