On Wed, 28 Nov 2012 07:31:32 +0100 Adrien Nader <adr...@notk.org> said:
well i'm behind in my backlog.. but i'm onto this now. :) > Hi, > > I'm interested in bindings to several libraries but I don't want to do > it by hand. I definitely prefer to automate their generation. > > Unfortunately, some type information is missing. The best example is > probably with lists and other data structures: eina_module_list_get() > returns an Eina_List but what is the type of the elements inside it? In > this case, it's an Eina_Module list: quite understandable to humans but > unusable for automated tasks. > > For some languages, lacking this kind of information prevents building > an API with a native feel and is even dangerous sometimes. C++ would > call them "std::vector<eina::module>" or so, Go would have "list of > Eina_Module", OCaml would name them "Eina_Module list". > > The Glib people did it (almost) right and have annotations in their > code. There are two interesting documentation pages about it: > > https://live.gnome.org/GObjectIntrospection/Annotations > https://live.gnome.org/GObjectIntrospection/WritingBindingableAPIs > > I definitely don't agree with everything there but it's worth a quick > read to see ideas and examples. > > This leaves a couple questions: > - can doxygen be used to extract annotations; if not, I can write > something reliable to do it no. i dont think u'll find doxy comments helping much here. > - which format to use (glib uses S-expressions which are simple to > parse) hat i don't know, BUt... i think maybe its a good idea to look at eo. eo is our new ans shiny objecty thing going into efl. it wont help u with the current "c style old efl api"... but it'll help u in the future. its basically putting a unified oo layer under all of efl - or most of it thats objecty and it allows for introspection and unification of things like callbacks etc. it should cut down the workload of generating bindings massively anyway.. and could work at runtime. with libffi u can generate varargs on the fly. > I'll also mention a few more benefits of more annotations and more > bindings: > - makes some bad APIs more obvious > - finds irregular function names > - better developer documentation (thinking about the exact return type > of eina_module_list_get() late in the day after a very stressful day > didn't prove very successful for me) > - exercises more parts of the code > - can bring some interesting concepts (and I already have a secret > experiment planned :-) ) agreed there. as its TESTABLE documentation - ie if bindings fail.. then the doc is wrong. :) > Any comment? Overall I find Glib's annotations to be pretty well-done so > I'd be tempted to do it similarly. > > Also, without such bindings, I'd be forced to do more GTK+ and less EFL > (plus I pay beers). ='( understood. i think annotating sounds good, but given the workload we have so far, this is going to have to be a low priority thing. :/ > -- > Adrien Nader > > > ------------------------------------------------------------------------------ > Keep yourself connected to Go Parallel: > INSIGHTS What's next for parallel hardware, programming and related areas? > Interviews and blogs by thought leaders keep you ahead of the curve. > http://goparallel.sourceforge.net > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
