Quoting Prasanth Somasundar (2019-06-01 04:21:18) > Except for module names. Like I said, I'll try to fix this as best I > can and see if it makes sense to pursue. My current plan is to > topologically sort the graph, break any cycles with extra generics, and > then hide the generics in `Internal` modules. Not 100% it'll work, but > we'll see. It's fairly complex, but I would feel better about that than > presenting long names with no escape.
You may run into some trouble with this due to the fact that Elm doesn't let you re-export values imported from another module. So, there's no way to import a data constructor from anywhere other than the module in which it was defined, iirc. If you decide to go this route make sure you write some proof of concept modules early on to verify that the code you intend to generate will actually build. It's your project, but my advice would still be to keep it simple. I spent far longer than I care to think about banging my head against this kind of thing. As has been discussed, deeply nested namespaces generate painful APIs even if the target language has the needed namespace support, So I really think well-written schema should avoid them anyhow. And it is always possible to modify a schema to change the names and namespace structure without breaking wire compatibility, so one is never *really* stuck with what upstream has given them (e.g. I see why Kenton doesn't want to change the sandstorm stuff, but there's no reason I couldn't use my own forked versions to write apps). Best of luck, whatever route you decide to go. -Ian -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/capnproto. To view this discussion on the web visit https://groups.google.com/d/msgid/capnproto/155940854142.15918.7713439203705816260%40localhost.localdomain.
