On Sat, 29 Dec 2012 02:14:07 +0100 Cedric BAIL <cedric.b...@free.fr> wrote:
> On Fri, Dec 28, 2012 at 11:55 PM, David Seikel <onef...@gmail.com> > wrote: > > On Fri, 28 Dec 2012 22:31:18 +0000 Michael Blumenkrantz > > <michael.blumenkra...@gmail.com> wrote: > >> 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? > > > > 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 ? edje_object_add() The client is coming around tonight, and now I'm a day behind. So I'm not gonna be spending any more time beating at it to help you diagnose things today. The fact that it just worked perfectly with no error messages in merged efl tree is what took all the time tracking down, coz I was looking everywhere else to find the problem. lol -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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
