search

switchupcb / copygen

Go generator to copy values from type to type and fields from struct to struct (copier without reflection). Generate any code based on types.
https://switchupcb.com/copygen-license-exception/
GNU General Public License v3.0
352 stars 22 forks source link

New parsing #14

Closed f0mster closed 2 years ago

f0mster commented 2 years ago

Remove unnecessary complexity in parsing. Now it works with already parsed by GO types, instead of walking on AST tree.

switchupcb commented 2 years ago

All of these commits state "new parsing". Can you please explain how this parsing works?

Also, please see: https://github.com/switchupcb/copygen/pull/9#issuecomment-984746165

f0mster commented 2 years ago

I switch to parsing using packages. After calling packages.Load we have all data that we need. There is no need to walk by AST, and collect information about types, we just need to walk by types.Type and analyze it. The only thing that is absent in packages is comments. So to collect data from comments we still need to walk by AST, but it became much simpler. Code became much easier and it opens doors for future changes.

switchupcb commented 2 years ago

Please create a pull request (i.e on a separate branch) with solely the new parsing feature so I can merge it. Preferably after the implementation of integration tests (but not required).

This is done because the other commits are solely applicable to the pull requests you made; but not this one.

switchupcb commented 2 years ago

It's correct that go/types should be used, however I was unable to merge or cherry pick from this for several reasons. This doesn't mean your code was bad.

The project architecture is misplaced with parser file writing code in the cli and models that contain weird fields (i.e generator). The parser itself has code that doesn't seem relevant or is not labeled. There are also a few issues with the go/types implementation in the long term. For example, Copygen interface is searched for with high cyclomatic complexity and unnecessary type assertion. We don't need to track imports with 3 maps. Your implementation of functions.go searches for the go types interface, but doesn't use the function's types. It is also coupled with template implementation (which can be cherry picked in a different pull request). There are a few other things, but this PR will be closed.