Hello, On Fri, Dec 28, 2012 at 11:17 PM, Lucas De Marchi <lucas.demar...@profusion.mobi> wrote: > I'd like to start a discussion about eo and its usage in EFL. I got > very frustrated on how it was merged regardless the opinion of the > other EFL developers. IMO it could make some sense in elementary, but > not in the core like ecore, evas, edje.
It does, just everything is not done yet. See below. > Asking around I discovered I was not the only one.... rather the > opposite - everyone I asked hates how it's done. Recently I had to > review some patches to elementary, adding the systray support. My eyes > were bleeding. I will enlist here some reasons in no particular order. > Surely there are more... others are welcome to fill them here. > > - We replaced the function calls with eo_do(func()). Now, take an > application and imagine all ecore_*, evas_*, elm_* functions replaced > with eo_do(func()). This is not just ugly... it's impractical to use. Why ? You have less to type than before and you can now mix function call from different name space. It does bring benefit by reducing the need to check EINA_MAGIC for every API call for example. It still provide type checking to some extent at compile time. It also open up some load time improvement by reducing the number of symbol to link. Later on we can split the enum and the legacy api in two library, so application that only use eo_do will have the benefit of a faster startup time. By having one entry point we can now improve our debugging infra quite a lot. For example, instead of returning pointer, we can return an ID and check if it is still valid before touching it avoiding safely all use after evas_object_del for example. We now have weak reference and refcounting. There is also some possibility to reduce memory usage and run some gc to compact memory as needed. > - eo_do() is the userspace incarnation of ioctl() - search on LKML to > see how it's hated there. As far as I know ioctl doesn't have any type checking at compile time. > - *every* "function" in a backtrace comes with the > _eo_dov_internal()/_eo_op_internal() companion - besides polluting the > bt, for sure they have a cost. And I saw no benchmarks on mailing list > after the addition of eo. One might think that since *I* am > complaining, *I* should provide them, but I think it's exactly the > opposite - people who added this thing should make sure it's now the > same or better than it was before. I did benchmark at every point when this was added in trunk. You will see some patch from me in evas_render code that was linked to some speed regression. Over all expedite suffer a less than 5% slow down (without using directly eo_do API). > - If we really needed this level of OO in ecore, evas, edje, we'd be > better off using C++ or inventing our own language to fit our needs > instead of doing what we are doing now. C++ is not really sweeted for ABI/API stability ( for reference : http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ ). With EO, we only have two rules to follow: only add new enum at the end of the enum list and never remove any inheritance link. Every think else is good to go. That's of course without talking about startup time... And also live debugging feature. There is an ongoing work on integrating clouseau and eo. This mean we will be able to also walk the list of all live object in a running program. For large program like Enlightenment, this open up the possibility to check how many idler, timer, animator, ... are sitting around and how we can optimize our stack. That's why moving Ecore to Eo make sense. One infra that help every one. In fact Eo will help us a lot in writing an EFL IDE. > - why is it any better than the smart object we had all these years? > Why not improve that instead of replacing with eo? Because smart object is really far from any useful object model. No multi inheritance. Highly tied to evas_object... I will let you continue on that list, just look at Eo feature and you will see everything that smart object are lacking and can't get. > - run elementary_test with EINA_LOG_LEVELS=5 and see the > construction/destruction party That is something I think is annoying to. It is clearly to much verbose for nothing, should be fixed in my opinion. > - Despite raster arguing this is not an API break, I strongly believe > it is. It broke compilation of lots of c++ applications (I'll not > repeat myself here... in the mailing list there are my other arguments > why it is an api breakage) Yes, in C++ you can't change a returned type ever or it break ABI/API. That's a C++ issue. Regarding C++, it is now much more easy to provide a clean binding to EFL that will have much less chance to have his ABI/API break. -- Cedric BAIL ------------------------------------------------------------------------------ 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. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
