Given that I replied to one message, I have to agree with Henrique here. If you're a C programmer, having to work with C-unlike code is a PITA. I can cite 2 examples that drove me away because of their weird usage:
- DirectFB: http://directfb.org/docs/DirectFB_Tutorials/image.html the exception-handling like, also the methods are in the instance rather that on the class to simplify usage... why not just doing in C++ then?! - libev: macros to "simplify" parameter passing and others: https://github.com/joyent/libuv/blob/1e32cb01b5ae20be0d27fa05ee1555b3f67bf763/src/unix/core.c#L266void ev__run (EV_P_ ev_tstamp waittime);... Even node.js stopped using that, code starts to be unreadable. On Sat, Dec 29, 2012 at 1:06 PM, Henrique Dante <hda...@profusion.mobi>wrote: > On Sat, Dec 29, 2012 at 12:48 AM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > On Fri, 28 Dec 2012 22:31:18 +0000 Michael Blumenkrantz > > <michael.blumenkra...@gmail.com> said: > > > >> 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? > > > > 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 > > Hello, from a new developer pespective, I think Eo is creating an > unwelcome encapsulation of the API, that's usually neither expected > nor wanted in C. It's replacing simple function calls with message > building with handles and varargs. The way I see it, new C application > developers from the community (as opposed to employees required to > work on EFL) which could potentially choose EFL as a toolkit, would > avoid it, not be attracted to it. > > While developing with Eo I also noticed that it breaks cscope usage. > Whenever I wanted to jump to the definition of some method call, I > reached a macro in the include file instead. Then I had to use the > method ID to do a new search, this time not by definition, but by > usage in class definitions. The other way doesn't work well either: > single stepping in gdb to find out the code path or looking at a > backtrace are both polluted with Eo calls. In general single stepping > on an efl method call should take 5 seconds, but with Eo it may take 5 > minutes. Main negative conclusion about this is that there's no > trivial way to find out what an Eo call does, and this will discourage > new developers from reading code. > > > 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) 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 > > > ------------------------------------------------------------------------------ > 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 > -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ 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_123012 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
