Why WebIDL over EmBind? #3232
-
|
Something i have been wondering about for q while, why was the WebIDL binder chosen over the seemingly more popular & complete EmBind? Was it because it is more easily parseable and the automatic generation of types was a goal from the start? Was it because of a bug/limitations in EmBind? Was it just a guess? If you were to make the choice again, would WebIDL binder still be chosen, or would EmBind be chosen? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
I started with embind, and it turns out to be complicated to use, not super flexible, quite verbose, and because of some magic I think it was not handling properly the shared pointers. WebIDL might not be "sexy" compared to Embind, but it just works, allows us to generate types, allows us to rename a type (gdObject), works with typedefs, uses a standard syntax (WebIDL), does not require a new .cpp file to compile (just Wrapper.cpp), so overall I'm pretty happy and would use it again I think. |
Beta Was this translation helpful? Give feedback.
I started with embind, and it turns out to be complicated to use, not super flexible, quite verbose, and because of some magic I think it was not handling properly the shared pointers.
See the commits that actually did the changes 4 years ago: 4ian/GDevelop.js@e654ec3, 4ian/GDevelop.js@3ed1515#diff-3b1a2a3a954dfdd8a93286806c5fd589516db4cd2f2704fbb823482a91cf4bfc
WebIDL might not be "sexy" compared to Embind, but it just works, allows us to generate types, allows us to rename a type (gdObject), works with typedefs, uses a standard syntax (WebIDL), does not require a new .cpp file to compile (just Wrapper.cpp), so overall I'm pretty happy and would use it again I think.