Closed nissim-natanov-outreach closed 2 years ago
@jmattheis for now, I have decided to fix the bug only: do not let extend with pkg load unexported - this bug prevents us from using 'private methods' in the convert-dedicated libraries - and that is just awkward. The other feature related to unexported (ignoreUnexported) feels low prio for us ... so I will shelve it for now.
Merging #17 (6cb6dd1) into main (edc349e) will increase coverage by
0.05%
. The diff coverage is100.00%
.
@@ Coverage Diff @@
## main #17 +/- ##
==========================================
+ Coverage 93.78% 93.83% +0.05%
==========================================
Files 22 22
Lines 1078 1087 +9
==========================================
+ Hits 1011 1020 +9
Misses 51 51
Partials 16 16
Impacted Files | Coverage Δ | |
---|---|---|
generator/extends.go | 95.31% <100.00%> (+0.35%) |
:arrow_up: |
generator/packages.go | 92.00% <100.00%> (ø) |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update edc349e...6cb6dd1. Read the comment docs.
This PR blocks use of unexported methods when using extend with package path. In vast majority of the cases these convert methods will come from a package that is not the same as the target/generated one: an unexported method in this package can mask an exported one and the code won't compile.
If desired, we can consider enabling the use of unexpoted methods under special extend flag. To make it easy for the future I moved the 'decision' to allow unexported methods (and at the same time the Converter interface) into ParseExtendOptions. Hope this will reduce 'hidden assumptions' relying on convertInterface and also make it easier in the future to enable new extend flags.