On Thursday, March 4, 2021 at 10:06:01 AM UTC-5 Bryan C. Mills wrote:
> > I would argue that the “hack” in this case is the approach of defining the > API in terms of copying in an entire tree of packages, rather than having > users of the API make function calls into a specific set of (unmodified, > un-relocated) packages with stable import paths. > > If the API is defined in terms or reflection over a set of types, why > substitute a package rather than (say) having the caller pass in a set of > instances of `reflect.Type` or similar? > I'm not trying to create an API. My initial goal is to provide a working skeleton app for my own use that incorporates: - a server, - a wasm client, - a web page that loads the client, - a common struct that represents information to be displayed in the page, changed by controls therein, and propagated back to the server through the wasm client. - magefiles and templates that generate code in the server, client and web page such that changes in the common struct are updated in all of the above at build time. The above functionality is working pretty well. I can modify, add or subtract members in the common struct, rebuild and run it with no other manual changes. I posted here because of the problems I've encountered with Go modules when trying to create new app from a clone of the skeleton. If I can make the skeleton broadly useful and make it play nice with Go modules, I'll happily share it. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/d83c42f9-0892-49f4-b41c-fdd05e216eb1n%40googlegroups.com.
