On Sat, Dec 29, 2012 at 10:32 PM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Sat, 29 Dec 2012 13:06:25 -0200 Henrique Dante <hda...@profusion.mobi> > said: > >> 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. > > if you see a bt with eo stuff - ignore the eo stuff and just skip to the bit > that does the real work. can't fix that without patching gdb. not sure it'd be > wise either. can't do much about cscope except write better tools or patch > cscope itself. > > fyi - we plan to make better tools. we've been tossing about making our own > ide. this is where we get to be able to solve things like this.
People tend to work in several projects. Having one IDE for each one is just insane. I myself work in projects from bootloader and kernel to a handful of userspace projects. VIM fits my needs for all of them. You are not convincing anyone to use a shiny new IDE built with EFL just because EFL needs some weird tooling. > > the extra eo layer underneath a thin c call layer is unavoidable as that's > needed for compat (abi/api) anyway. but we have been told this is *only* for compat. Not for new calls. > > the alternative is "rip all of eo out and don't do it" which imho is I like this alternative sooooo much :-) > unacceptable the other way - code using efl stays messy and inconsistent. we so you are saying it has been messy all these years? And all the other similar libs are messy too, since they don't have anything similar to these macros. > have no path forwards to improve things and unify efl. reality is day in and we sure can improve things without eo. this is what we have being doing all these years. > out people turn up looking at efl as a single unit. not as a collection of > separate libraries. they expect it tobe a single unity with a single model and > after years of that eo is a way of sliding that in without breaking what we > aleady have. it's a path forwards. there is an eventual idea that we can move > to a single libefl.so (with libeina.so/libevas.so etc. being simply thin c api > wrapper libs on top), because this simply is what people are asking for. maybe > not YOU, but i'd say 9 out of 10 think this way, and expect this and want it. We could very well ship a single libefl.so with NO need of eo for doing that. We could do this right now or have done this even before efl 1.0. This is no argument in favor or contrary to eo adoption. Lucas De Marchi ------------------------------------------------------------------------------ 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
