On Fri, 28 Dec 2012 22:31:18 +0000 Michael Blumenkrantz <[email protected]> said:
> On Fri, 28 Dec 2012 20:17:14 -0200 > Lucas De Marchi <[email protected]> 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? fair enough. it's a change. it's not a change i wanted. it's a change that was NEEDED. needed because once you go beyond the scope of us few efl devs, you hit a wall of developers who can take our api - documented or not, with examples or not, and then just fall over tehmselves and end up wasting our time by the bucket load in the process. you never experienced it so you never felt or sw the pain. you were insulated. this change is some of that insualtion not able to continue and something has to leak. it has to give. if this demotivates you, then i guess, so be it. continuing as we were would have demotivated me to the point of giving up. it also *HAS* deotivated a dozen+ other people. so we lose either way. without eo peolpe doing bindings do them the hard way - forever. eo provides for introspection and documentation. without eo we have our "17 ways to a callback". maybe you don't get annoyed by this, but i do. i keep having to try remember "ok, which prototype was that callback? i know its void *data... then what? what does it return?". eo tries to unify callbacks... AND document them at runtime even (for introspection purposes). this makes it insanely easier to build a gui builder and make language bindings. without eo we still have the danger that code messes up and you accidetnally access an invalid pointer... nd then segv. and hen you should know the wonders of this... you get a complaint "e crashes!"... and you get no usefl backtrace from the user (or not even a backtrace at all). object indirectiona and ids stop that. or more accurately, bring the likelihood of it so close to zero it may as well be. something has to stomp over the object id table to make this hapen and if we mmap the ob id table in its own memory mapping, then the chances of an errant write to this memroy are very close to nil - you cao't walk of the end of your malloc()ed segment into it. it has pages padding it. it's in address range never exposed, so no one actually holds pointer values to the table EXCEPT for a very small sliver in eo. this table isn't there right now. but the plan was to slide it in and have it there. crashes now go down dramatically. invalid accesses are safe and detectable without signal trapping. this holds tr not just for e17 but for everything using efl. without eo we have to handle cleanup of attached things like timers, animators and just random "extra stuff" you ay attach to an object (eg an edje object) where you don't want to go make a whole smart obj (class) for it - you just wanted to stick on a timer to time out in N sec and then do something. but you now have to handle all the cases of if the oject is deleted before timer expires. if timer expores, ensure the timer handle attached to obj is nulled out, and you have to attach it somehow. with eo you can just create and attach and "walk away" and the rest is handled. it lowers the bar to making objects like this easily and safely, saving you time. right now eo looks bad to you because you see the downsides only and make use of none of the upsides. that's part of the transition. i think it's good to air this as to a lot of devs they are unaware of why eo is there, and what caused its ned to become reality, and what you get in return. until its actually being made use of evrywhere, it won't reach full potential, but if its not being used at all (which is pretty much the case at the moment) all it has is apparent and real downsides (longer bt's call overhead++ etc.). -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
