Closed claytonrcarter closed 2 months ago
Compounding some of these considerations is the fact that phpDoc is ultimately just a comment, and is prone to creative uses, some of which are "off label" and/or invalid. For example, I don't think that @see $this->methodName()
is valid phpDoc, but that doesn't mean it's not in use in the wild. Not that I'm suggesting we explicitly support that, but if we someday decided to, it would be as simple as dropping member_call_expression
into the defn of _see_tag
. (Ha! how's that for underestimating complexity?!)
On top of that, if I, as maintainer of a syntax highlighter for PHP, want to capture all uses of $this
w/i member call expressions, I can just develop my query w/i the PHP grammar and know that it can be reused more or less as-in w/i phpDoc. (More complexity underestimation!)
Anyway, my 2 greatest concerns are around:
@see $className::someMethod()
and much more concerned about implementing our own parsing logic without realizing that we're not allowing some oddball PHP construct that should be valid there.Bottom line: both of these come down to me being a little bit lazy but also a lot not comfortable w/ my own expertise in parsing PHP. I don't have the capacity to research all of these edges, and reusing the PHP rules allowed me to get "close enough" to get things working for most cases.
I don't recall what made this issue important initially, but everything seems to be fine for now. Closing as a non-issue for the time being, but we can reopen if/when it becomes a problem for someone.
This grammar is currently using the
tree-sitter-php
grammar to do some of the "heavy lifting" for parsing language constructs that are common between PHP and phpDoc. @mikehaertl raised questions about this approach in #14. Here's my take:Pros
tree-sitter-php
w/o having to duplicate the fix/update.Cons
int[]
) and grouped types (ie(int|float)[]
which are not supported in PHP.class-string
,positive-int
,non-empty-array
, etc