On Fri, Dec 28, 2012 at 11:55 PM, David Seikel <[email protected]> wrote: > On Fri, 28 Dec 2012 22:31:18 +0000 Michael Blumenkrantz > <[email protected]> wrote: >> 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? > > I'll add my two cents worth. > > Initially I think I was keen on the idea, but was waiting to see what > the implementation was like. It did worry me that we seemed to be > getting more than one OO system being worked on at the same time. > > However, I've just wasted a whole day tracking down that I was passing > an Evas_Object to a function that needed an Evas. It compiled and > worked fine under the merged efl tree, but not on EFL 1.7.4. Under > 1.7.4 there was no complaints, just missing text.
This is cleary a bug, it should have triggered a critical warning at run time. Care to share which function ? -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
