Open janbormet opened 1 year ago
I have a WIP PR to moleculec-go that may help this: https://github.com/driftluo/moleculec-go/pull/7
This PR will help people to get a more generic way to generate type interfaces for realworld usage, reduce hand wrting type reflection(?) codes, and is convinent to use as the example shows. Will push to finish it soon.
Once this pr was merged, ckb-sdk-go will updates its molecule package
If you want to generate go-code for molecule types that depend on and import types from
blockchain.mol
, the moleculec-go backend (version 0.1.11) produces code that needs to import the generated blockchain types and functions from themolecule
package (essentiallytypes/molecule/type.go
).There are two (related) issues with this:
1. The generated code does not qualify the names from the imported
molecule
package.You could get around this by e.g. importing as follows:
One would still face problems, if one wanted to include types from different source packages (as there can be at most one dot-import as far as I know).
2. The moleculec-go backend produces and uses unexported functions (e.g.
func packNumber(num Number) []byte
).As far as I know there is no way to "extend" remote packages in go and thereby make such functions visible and callable. The result is that the generated code (located in our project) that depends on
ckb-sdk-go
'smolecule
package's generated types forblockchain.mol
will not compile. A naive solution would be to just copy thetype.go
file into your local package, but this heavily restricts interoperability with the functionality inckb-sdk-go
as they would obviously be different types as far as the compiler is concerned.Our current (unsatisfactory) solution for this is forking the
ckb-sdk-go
and placing our generated types directly next totype.go
in the sdk'smolecule
package. See: https://github.com/perun-network/ckb-sdk-go/tree/perun-types/types/molecule In thego.mod
of our project using this we then do the following:FYI: If you want to try and reproduce this, you can find our types here
This solution also "solves" the first problem. It works for the compiler, but the disadvantages are apparent...
Our questions are:
I feel like the best fix for this is through the moleculec-go backend. One could (a) qualify imported types with a package name and (b) avoid using non-exported function names.