On Mon, Dec 31, 2012 at 2:20 AM, Cedric BAIL <cedric.b...@free.fr> wrote:
> On Sun, Dec 30, 2012 at 10:48 PM, Gustavo Sverzut Barbieri > <barbi...@profusion.mobi> wrote: > > 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. > > Indeed the eo_data_get doesn't allow that. I have been working on a > proposal to solve that problem and open some more possibility. I > planned to write a mail later this week. Anyway the idea is to move to > an api like a rw mutex. So that as long as you hold a pointer to it, > it wont get compacted. Main target are currently Evas and Edje where > it would help and the code affected is not that big (basically mostly > in canvas/ subdirectory). > > > ID indirection helps what? making debug harder? > > You get an assert as soon as you use or reuse a wrong pointer. Instant > backtrace that point to the source of the problem. Zero delay. No > hiding. It will help application developers that tend to still > manipulate dead object. > > > 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. > > nm + shell is a very limited tool to check for API/ABI stability. It > completely ignore structure and enum. So it's worse but anyway relying > on nm + shell for doing an automated test here, is really a wrong > argument. If you want this kind of tool, you will need to move to a > llvm/clang's plugin anyway and that kind of plugin would be able to > check API/ABI stability for EO. > > > See, you can't still change the parameters. You can't change the return > > type. You can't change the function name. > > This is not C++, you can change the parameters and return value as > long as they remain opaque. As for changing the public name of a > function, I don't see how you could still provide an API/ABI > compatibility with such a feature. But as we are doing C, API/ABI > stability is almost an non issue here compared to other language > (which was my main point on that subject). > > > 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. > > This is debatable. I do think that a 1:1 binding is fine as it provide > an easy and sure path with time. Still there is clearly a need to > implement a layer in the "binded" language to abstract it and make it > feel like a native JS, Python, whatever API. You may not have a 1:1 > binding in Elev8, but I think you are doing a higher up layer in JS > with EasyUI that could have been an abstraction between a 1:1 binding > and the JS world. I also think that this way the binding would have a > much easier time to provide a stable API and the script could just > include the EasyUI layer they used for development. That one would > have worked on every version of the binding without any breakage ever > and it would have make the life of maintaining that binding much more > easy. > > > 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. > > It's not worse, it just limiting and sad. You will be limited to use > only one function call even when you have all the value needed to do > much more... I also would have liked a way to bind that. > > > Then it's like fixing a problem that is not broken. > > Seriously ? Our binding are massively behind. We have barely one > maintained binding, JS and a few other that are slowly dying. If half > of our API was present in them, I would be happy, but that's far from > being the case. So what is the status of the Perl, Python, Ruby, Go > and all other bindings ? Tell me they are all great, cover 80% of our > API (I am not even asking for 100%) and well maintained. > > > 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". > > Seriously ? You want to rewrite EFL in Vala ? Wasn't it Go or Python last > time ? > I agree with Gustavo here. Not in Vala itself (I have used before and surprisingly it is very useful and works), but the fact that the solution of putting eo inside efl does not solve any problem. IMHO the problem raster has described can be resolved in many ways and the solution picked just brought in more problems. If the need was to provide a common interface so ELM developers can use for example timers, attach it to an object, urnef, ref, whatever, then what does an object system has to do with it? You can create an Elm_Timer that will wrap ecore functionality for you and you can safely use it on ELM. IMHO the problem with ELM is another, but that's another story ... If you want to have a common callback definition, then define it somewhere, in eina for example and make every efl lib use that definition, the OO system here isn't needed at all If you want to have bindings (and as automatic as possible) then you can go in the GIR direction (https://live.gnome.org/GObjectIntrospection/). The "problem" is that everything is picked from the sources (headers and source files) that means that the way the code has to be documented in a standard way so the parser can pick it up. If EFL took years to sanitize its code format, documentation might take more years :) At the end the problem with bindings is how to describe your code in a way that such description can be picked up by a binding developer and create it. As Jerémy pointed out, there are already solutions for that, being it libffi or whatever else and those are night linked with your code internals. With eo, now your code internals change and must match to what is expected and what eo provides. Sure you can modify it to fit your needs, but then your problem has suddenly changed and now you have a problem somewhere else. For example yesterday I created this ( http://code.google.com/p/enesim/source/browse/trunk/efl/efl_ender) with ender. Basically, is an "enderization" of evas API, a very naive approach if you take a look on the code and the evas.ender file, but it works very well. Check the test01.c and see how you can safely use ender api to manipulate evas api. But the good thing is that as long as one provides bindings for ender, any library that is described with ender can create the bindings automatically (maybe with some hand tuning in case the language has some shortcuts for some stuff). So this is another option to ease bindings. Again, eo here might provide a solution here, but it wants to be the swiss-knife for stuff that was not required. In fact raster's features about an OO library has nothing to do with the initial requirements. If the need was to have less memory fragmentation with the Evas Smart objects and avoid so much void * foo_data_get() to get the internal implementation, then use structs for that. But if you want to expose some structs on the .h to for example extend some objects, then you enter a nightmare of public/private attributes, then you enter the problem of declared size vs. real size, gobject already handles that, but at least for me, is over complicating yourself for not good reason. Another problem I see with eo, is how to define known types/calls? For example let's say that you want to generate bindings for an Evas_Event? it is not a type, it is a struct (IIUC eo types are only doable for "objects"). So every "binder" will have to manually describe every struct? Anyway, just my two cents based in the experience I had with ekeko (old oo approach), ender, gobject, vala, etc :) Regards > -- > 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_122412 > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ 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_122412 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
