djinni-generator
djinni-generator copied to clipboard
cross-language-cpp
Import Web Assembly support from snapchat's djinni fork
I felt quite inspired by @eakoli 's latest contribution. I'm not sure there's the appetite for this, but at least on my projects, if I'm using djinni in the future it's hard to imagine not wanting the possibility of a web assembly (and flutter?) target. This is quite a naive attempt to steal that from the snapchat djinni, and without the lib-side work (which I haven't done yet), I'm not sure it even works. Anyway, the way these things go I may have time to work on it some more and I may not, so I thought I'd make the (draft) PR now and then worry about the rest later.
Wow, that's a pretty fantastic development!
Just a question: After looking back at the Python addition, I see that it is now 80% to 90% done but then slowed down. Is there a danger we will end up in a similar situation (which might also be OK, because better 80% than nothing) Or can we have a sample Hello World app utilizing this WASM generator once it is no longer in draft state?
Yes, I think we need some kind of definitive sample for this to be moved out of draft status. I haven't checked what there is in the snapchat repository, yet. I understand your concerns about abandoned platforms, but (at least for me) web assembly is pretty essential. I think that, given the state of the support on the snapchat fork, it should be possible to get the web assembly support here quite usable without too much pain. Fingers crossed. Next up the support lib, I guess.
One of my general concerns with this PR is how many changes seem be outside of the new generator code, as in theory, adding a new generator should change little of the existing code other than extending the places to enable the new output.
E.g. Ive started working on a swift and kotlin generator and so far haven't had to make any changes to existing code other than adding the options and extra bools to enable them during testing
I agree, we need to check that all changes are related to the WASM part and not sneak in via any other Snapchat additions that might change behavior.
On the other hand, if the expected files from the tests are unchanged, nothing should have changed (or our tests are incomplete). So we should have some safety net in place,
One of my general concerns with this PR is how many changes seem be outside of the new generator code, as in theory, adding a new generator should change little of the existing code other than extending the places to enable the new output.
E.g. Ive started working on a swift and kotlin generator and so far haven't had to make any changes to existing code other than adding the options and extra bools to enable them during testing
I've been trying to reduce these changes. I think all that remains is the isOptional change/fix, which I think/hope is tolerable given that it has not forced any changes in existing expected generated c++ code.
I am sorry, but looking at my calendar, it is very likely my review must wait until the Christmas holidays. I want to prioritize these tasks, and I will try to do it, but it is difficult. Thank you for your understanding and patience.