Exported funcs, identifiers #14
Replies: 3 comments 2 replies
-
In general, I do agree the API should be updated. It's very much a work in progress. There is a lot of functionality that can be refactored. My initial goal was to be able to reliable implement the gedcom7 standard. I measured success based on the ability to import and parse a gedcom7 file and then export an identical file. A couple of considerations:
I definitely need to think through some of these issues to make sure changes support future work. I will need a bit of time to think through the implications. The PR you already raised gives me some insight into how the package could be used in an application. If you don't mind reverting the Makefile related changes so they can be moved forward now, that would help. Any input on this would be great! If we can keep the PRs smaller and have a roadmap for changes, I think we can accomplish what you'd like to see. |
Beta Was this translation helpful? Give feedback.
-
Possible roadmap:
It might make sense to also consider an interface for Node values. |
Beta Was this translation helpful? Give feedback.
-
Thanks for all the insight and consideration to the suggestions. I don't know a whole lot about the GEDCOM format, and I'm just getting started with geneaology myself, so I'd certainly take your lead on roadmap items and such. Having perused through the v7 spec, I have an idea of how challenging it is to implement, let alone multiple versions! One golang library that handles multiple versions of GEDCOM-formatted would be awesome. I can appreciate that it takes time to get right. This issue is rather open-ended, and could probably be closed for now. Would it make sense to set up this repo with Discussions? |
Beta Was this translation helpful? Give feedback.
-
split off from #7
Just some suggestions I had.
For package-exported identifiers, it's a good idea (at least, in my opinion) to ensure any referenced types and fields are also exported. Then it's easier to lookup the package API when doing
go doc path/to/pkg.Identifer
or when visiting the generated godoc page at https://pkg.go.dev/github.com/funwithbots/go-gedcom.The exported identifier could be concrete, like a struct type, or an interface.
Some places I suggest looking at are:
It might be worth considering an interface type for
Document
so that applications using the library are less likely to depend on implementation details that may need to change for whatever reason. Rather, the application would depend on an API contract (the methods in the interface).Beta Was this translation helpful? Give feedback.
All reactions