On Fri, 28 Dec 2012 20:17:14 -0200 Lucas De Marchi <lucas.demar...@profusion.mobi> wrote:
> Hey! > > 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. > > 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. > > - eo_do() is the userspace incarnation of ioctl() - search on LKML to > see how it's hated there. it does make me consider entering one of those code obfuscation contests... > > - *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. backtraces with eo are the reason I don't see myself ever switching to the 1.8 branch. as for benchmarks, I saw some supposed numbers thrown around during early eo development which claimed that it "was slower, but not that much slower, and worth it for the gains" > > - 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. > > - why is it any better than the smart object we had all these years? > Why not improve that instead of replacing with eo? > > - run elementary_test with EINA_LOG_LEVELS=5 and see the > construction/destruction party not to mention the spam just from running e > > - 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) > > > > My opinion is to revert the whole thing, but I'm sure this would be a > major task after the surgery to put it in was made. I'd at least like > the people responsible for it to answer the points above, and people > who like me think this is all crap to step up and say so. > > > > Lucas De Marchi > depressing though it may be to think about, I have to agree with your points. I'm not saying it needs to be reverted, but I don't see any benefit to keeping it unless the goal was to reduce my commits to the afflicted areas to near zero. while it's impressive that all of the eo stuff was added with relatively little breakage (as opposed to my expectations), the idea of having to learn what is essentially a different programming language in order to work on efl internals again in trunk is really demotivating. maybe I'll become the kwo of the 1.7 branch? ------------------------------------------------------------------------------ Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of 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_122812 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
