search

claytonrcarter / tree-sitter-phpdoc

PHPDoc grammar for tree-sitter
22 stars 11 forks source link

Improve FQSEN support for @see #14

Closed mikehaertl closed 2 years ago

mikehaertl commented 2 years ago

@claytonrcarter Bump :)

claytonrcarter commented 2 years ago

@mikehaertl Thanks for the nudge and thank you for your ongoing contributions and I'm really glad that you're find this useful, and helping to make it more useful!

Can you tell me more about how how you intend to use the (fqsen) node type? I had missed that when reviewing #9 and I'm a little bit 🤔 wondering if that node should instead be a hidden node (ie $._fqsen) just to help us in building the parser instead of a regular named node. Have you come across a usecase where you wanted to query for any FQSEN vs for a specific type of FQSEN? (I guess that gets back to the question of reusing the node types from the main parser so consumers could reuse the same queries in PHP as they use in phpDoc to find, eg scoped_call_expression, etc).

Again, I'm mostly wondering aloud and looking for thoughts and input; not set in stone.

Thanks again!

mikehaertl commented 2 years ago

Can you tell me more about how how you intend to use the (fqsen) node type?

Well it's part of the (semi-)official phpdoc specs like in @see [URI | FQSEN] [<description>]. We have a uri node so we should also have fqsen node. After all we build the phpdoc parser so IMO it's not surprising that our node structure may be a little different than PHP's. And PHP's node structure may not yet be set in stone either.

Regarding reusing PHP parser nodes: I see all your points and they make sense. But on the other hand I also have some doubts:

  1. We can't really reuse rules as they are. Instead we go deep into the internals of the PHP grammar and "cobble together" our own modified rules from them like here: https://github.com/claytonrcarter/tree-sitter-phpdoc/blob/8fae507a8d749f58958ba160f747231990fb55f0/grammar.js#L439-L446

    This gives me doubts if e.g. upgrades are really painless later (which is one of the promises of code reuse). We will always have to carefully inspect the updates in the PHP grammar and which of them are relevant. We may also have to pick them apart like above.

  2. In addition I found having to look at two grammar files makes things hard to follow if you need to dig into a rule. You need to be very focussed to not get lost. The heavyweight PHP grammar doesn't help in that respect.

These points made me wonder if the hassle of importing the PHP grammar is really worth it or if we shouldn't simply copy the few relevant rules into our grammar file. It would make our file so much easier to digest.

Also just thinking aloud here. Thoughts?

claytonrcarter commented 2 years ago

Sorry for the long cycle times on this discussion. TBH I'm still no settled on this, but I don't want my vacillation to block any more progress for you. This is clearly well thought out and executed. We can discuss the parser approach separately and make revisions if needed. Thank you!

claytonrcarter commented 2 years ago

Well it's part of the (semi-)official phpdoc specs

Yup, fair enough. I knew that, but just needed to be pushed over the edge. 😄

are you sure that this happy accident is really due to treesitter?

Not at all! 😄

For all other points, I'm going to create an issue for us to discuss the copy/paste vs import/compose discussion, and how to structure the parser.