On Fri, 28 Dec 2012 20:17:14 -0200 Lucas De Marchi <lucas.demar...@profusion.mobi> said:
> 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. it makes no sense to put in elm unless the base of efl also has it. a whole POINT of eo is so you can do things like attached a timer as a child to button and have it auto-deleted when the button is. in the end this all requires that anything you want to work this way has to be an eo obj. this is a result of real life problems with programmers doing things like making animators and timers and simply never cleaning them up when the "parent" object they worked on was deleted. they neve bothered to attach a del calback and track these things and then others end up with their days wasted hunting down these bugs because there wasn't a sensible and easy way to bind such thnigs together. > 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. anyting systray related makes my eyes bleed. > - 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. disagree. what we can do now is ammortise call costs eo_do(obj, move(10, 20), resize(30, 50), color(255, 128, 0, 255), show()); we have only 1 entry cost (eo_do). all the magic checks and so on are done onces for all of move+resize+color+show. there is a good reason for this. one of the intents of eo is to indirect object ptrs. frankly as above. people who can't read backtraces properly or handle memory well are wasting efl devs time aain and again. i want object ptrs "gone". that means obj * is actually going to become an ID and then an indirect table lookup. it's set up in such a way that it then impossible to access memory accidentally from an object handle. you either access valid memory or you know its empty. this raises the entry cost. offsetting that with multi-call per entry evens things out. my only unhappiness is lack of namespacing in c so we could have shotened the "func macros" to the above. > - eo_do() is the userspace incarnation of ioctl() - search on LKML to > see how it's hated there. vastly different. ioctl is used as a one-thing-at-a-time "stuff every func on the planet into ioctl via params". eo_do() is a protocol buffer. like write() but the compiler builds the protcol buffer for you on the stack which is much nicer. no it's not async. but its not ioctl(). very far from it. the only similarity is that it has a single entry point parent. (well actuallt you can do the same on eo_add - pass multiple method calls WHILE adding the obj so once returned the obj is already set up). > - *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. benchmarks have been done - it depends what you benchmark and how. it's in the 0-10% range of overhead. this was already expcted and a price we know we have to pay in return for other things. if you USE is as 1 eo_do() == 1 old evas/edje etc. func - then yes - expect that overehad. if you make use of the multi-call stuff.. overhead drops a lot. in fact you may begin to gain as we currently do magic number and ptr checks for every efl call. eo will ammortise its higher check cost over N calls, as long as you try and kep N > 1 then you're on the path to winning. > - 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++ would be a sledgehammer solution and comes with lots of downsides of its own. other languages too. the fact is we can slide eo in without rewriting in another language. the only thing really missing is namespacing. > - why is it any better than the smart object we had all these years? > Why not improve that instead of replacing with eo? see above. need ot lower down. also smart objects are evas objects. evas objects are big, fat and bulky. they consume a lot of memory. > - run elementary_test with EINA_LOG_LEVELS=5 and see the > construction/destruction party that was there already. we alloc and free events all the time. we construct and destruct things all the time. it simply now also has logging available to see it. > - 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. the only things i think that are bad are: 1. lack of namespacing so we still have long "funcs" inside eo_do() 2. the addition of backtrace gunk (can't really stop that without forcibly making the funcs in e into macros and then we just reduce it, and dont remove it - then again any internal funcs inside api calls would be "backrace gunk" too so in principle this isnt much different). > Lucas De Marchi > > ------------------------------------------------------------------------------ > 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 > -- ------------- 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. 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
