On Sun, Dec 30, 2012 at 10:04 AM, Cedric BAIL <cedric.b...@free.fr> wrote:
> On Sun, Dec 30, 2012 at 12:55 PM, Lucas De Marchi > <lucas.demar...@profusion.mobi> wrote: > > I don't want to be the boring guy complaining on this. But I can't > > agree neither on the reasons why this went in, nor how it went in. For > > me eo is just raping C and all the problems pointed out should be > > fixed elsewhere. > > Please describe how. For example how do you plan to link cleanly any > object from ecore or eio for example with any evas_object ? How do you > plan to give memory compaction ? How do you see we could do the ID > indirection ? How can we do a live debug of live object in a program ? > How do you provide multiple inheritance ? How do you provide API and > ABI stability over time ? How do you make bindings easier to keep in > sync possible ? Please share your idea. If you dislike Eo so much, you > must have an alternative in mind that solve the same issue that Eo > solve. At the moment, I only see rants and no care about the problem > that Eo address and the answer we have been giving here. > I was trying to stay out of this thread, everybody knows I hate Eo and was against this since the beginning, showing facts on problems it caused to debug. But with these arguments, you're being too naive an eo is the solution for everything is not working. the memory compaction, for example, is independent and either you found out the "light" that nobody else did, or you'll face huge problems if you try. Not everywhere uses eo_data_get(), then if you replace the memory with some other address underneath, you'll end with lost pointers, garbage and it will be super-hard to find. The change will not be doable in the code base of our size. If may have worked if we started coding like that from day0. ID indirection helps what? making debug harder? ABI/API stability is worse, not better. You still have the same problems you had before, but the existing tools to check that (nm + shell scripts to compare 2 libs) won't work... and the worse part is simple: before you could reorder the functions around, now you must keep them in order as they imply an ID and it can't change. Okay, this is very minimum, but it is worse, not better in that regard. See, you can't still change the parameters. You can't change the return type. You can't change the function name. Bindings: I'm still to see that for real, but IMO it will make bindings worse. Also, people tend to think of bindings as a simply expose C functions in that language 1:1. This is horrible, you're developing for some language and you must cope with that language's style as much as possible. If the work to make the Python or JS bindings were just to generate 1:1, it would be better, but we took the time to think how to match language nicely. For bindings, the worse part here is that you'll never be able to construct va_list then you'll never be abe to expose eo_do() itself. Then it's like fixing a problem that is not broken. Raster had better points, which could be easily fixable in a simpler way (unified callbacks, references, type). The Eo is bringing a problem, not solving one :-( Actually it would be better to have invested in something like Vala, that looks like a higher level language that translates to C, other than doing this in C and having to solve problems everywhere else, like tools, debugger... the so called "e ide". -- 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
