On Sat, 29 Dec 2012 11:48:36 +0900 Carsten Haitzler (The Rasterman)
<[email protected]> wrote:

> 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.

Ah, so I'd have to redo the Lua bindings to use eo soon?  That will at
least get my hands dirty with it, then I can give a proper whinge, er I
mean opinion.

Introspection is good, I love introspection.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.

Attachment: 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to