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

Can't properly determine Object_'s name without context #236

Open
Amegatron opened this issue Feb 6, 2022 · 2 comments
Open

Can't properly determine Object_'s name without context #236

Amegatron opened this issue Feb 6, 2022 · 2 comments

Comments

@Amegatron
Copy link

Amegatron commented Feb 6, 2022

Consider such PhpDoc comment as an example:

/**
 * @param DocBlock\Tags\Var_ $varTag
 *                                  
 * @return \My\Super\Class
 */

When parsing this, I will have two Object_'s, one for DocBlock\Tags\Var_, second for \My\Super\Class. The problem is that if I have no context, (string) $object->getFqsen() will return them both with leading slash:

\DocBlock\Tags\Var_
\My\Super\Class

While $type->getFqsen()->getName() will return just the last part of the name for both of them:

Var_
Class

Meaning, that I can't get the original form of the reference without specifying the context, which I don't actually want to, cause it is redundant in my case.

@jaapio
Copy link
Member

jaapio commented Mar 29, 2022

Hi,

Thanks for your report. Can you please explain what you are trying to achieve?

The context is critical for this library as it tells us the imports that are done in a file. The notation DocBlock\Tags\Var_ is only valid when a context is provided. I think there is some assumption in the code that will automatically prefix the class names with a \ to ensure they represent a valid FQSEN. As the name explains an FQSEN is the fully qualified structural element name. This MUST start with a \.

This behavior is qual to what PHP expects from the code.

I hope this makes things a bit clearer for you. If you could elaborate on your use case I can have a look at how we can support this.

@Amegatron
Copy link
Author

Amegatron commented Mar 29, 2022

Well, my main point was about separation of concerns. Or in other words, I'm talking literally about parsing just DocBlock independently from where it is. I'm currently myself out-of-context a bit (that was almost 2 moths ago already), but I'll try to revise what I had there and why it was a bit redundant for me to pass the context. But in general the case was what I described: I needed to parse just the DocBlock syntatically. And the "context" was taken into account higher in my code hierarchy. And when doing this, I wanted to get original DocBlock\Tags\Var_ as it is, and apply the real namespace in the other place of my code. Or in other words, here, where I needed to parse DocBlock, context should not even be known by design. But I still had to pass it for workaround, though it's a bit wrong from the architectural point of view. So, revising, the problem is if don't have a context (which is actually optional in the API), I can't get the original writing DocBlock\Tags\Var_. Only either with leading slash, ro just Var_, which makes it impossible on higher-level code (wich is aware of "context") to determine the real reference.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants