List of snapchat features and fixes
paulocoutinhox opened this issue · comments
Hi,
This is the list of Snapchat features and fixes:
- Added move assigment operator to GlobalRef in all djinni_support.hpp files
- Made JniClassInitializer constructor public to allow arbitrary additional initialization in JNI_OnLoad()
- Speed up string passing between Java and C++ (about 5-10x faster depending on string size)
- Eliminate CppProxy finalizers (better stability)
- Injecting code with DJINNI_FUNCTION_PROLOGUE
- Option to generate ObjC protocols
- Option to generate function prologue
- Option to omit objc helper methods
- Option to disable exception translation in ObjC
- array<> type support
- outcome<> type support
- Protobuf type support
- Local flags with @Flag directive
- DataView for copy free data passing
- DateRef for copy free data passing with ownership
- Generating string names for C++ enums
The question is:
What of this we can bring to "djinni-generator"?
Thanks.
I'd be most interested in (in order) 4, 11, 14/15.
Thank you for the list Paulo!
Here some first quick feedback
ad 3
I think this is not an universal solution, but optimized for 1 use case, and by bringing the Java String presentation into the C++ part.
ad 4
targets a very exotic problem that hardly ever happens,
and the way it does it (at least that seams to me) is catching an exception/problem and throw it away
not sure if this is an improvement. It for sure avoids crashes in a problem scenario, but I know about project where that would be forbitten and you have to crash/restart
ad 10/11
shouldn't it be possible to model array / outcome and other types already via yaml types ?
ad 12
needs explanation (at least for me), what does it mean ?
ad 16
should be possible,
ad everything else
Needs (or at least I need) explanation what this actually means, or would mean in terms of impacts, breaking changes e.t.c
general
Lets us remember on difference between this version of djinni and the snapchat one
Snapchat is targeting 1 use case, that is their owns,
This djinni version targeting much more use cases and a wider user group
And not to forget, no one is working full time on that project. So what we can port is also a question of available resources.
However, I think this list is a great help to look info features we could explore and find out what it is possible to add.
Great done Paulo!
Hi folks,
You can find the explanation to most of these questions in the README.md file.
Also regarding $4 (finalizer). 1) they do actually cause random crashes, despite quite rare. 2) finalizers are deprecated in Java 9 so we might as well just get rid of them sooner than later.
Regarding $11(outcome<>), you are quite right that it could potentially be implemented using the yaml without touching the codegen part. I'll give that a try at some stage. Array<> on the other hand, requires the help from the codegenerator to get the java class name.
They also have some blog posts explaining some of the decisions: https://eng.snap.com/improving_djinni
Hi,
As i sad in snapchat repository, will be nice if we join efforts in only one project to make it grow with all the features together, because we cant use some features from one and some from other. Will be more productive if everyone works to djinni together in one repository and it grow without multiple forks. Everybody dedicated to only one djinni repository with all nice features from all minds.
This it is only my opinion.
The beauty of open source is that it is possible to have special flavors of a project.
As mentioned, not all improvements / optimizations are possible to implement as general improvements that cover all possible use cases, some will always cover some very special need and might work not that optimal for other needs.
But it's super nice to have projects that can inspire each other!
In fact, we saw already some improvements, on our seit in any case, but I also think other implementation take inspiration from what is happening here.
Introduced to the snapchat fork since this list was published, but I would be interested in their work on supporting futures.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.