On 11/08/16 11:39, marcel-hollerb...@t-online.de wrote: > Hello, > > sorry for joining in so late. > > On Wed, Aug 10, 2016 at 03:41:00PM +0100, Tom Hacohen wrote: >> Hey there, >> >> Sorry it took me so long to get to this one. I've been dealing with >> other things, and every time I got back to this I had more clashes and >> hell. I'm finally at a stage I can merge most of it, so I'm happy, >> though I have one question before I push. >> >> At the moment I changed it as follows: >> Eo.Base -> Efl.Object >> Eo.Override -> Efl.Object.Override >> >> I'm quite OK with this change. The problem comes with the actual >> functions. At the moment they are: >> >> efl_ref() >> efl_add() >> efl_del() >> efl_finalize() >> efl_name_set() >> efl_parent_get() >> >> Are we fine with these names, or should they be: >> >> efl_object_ref() >> ... >> efl_object_parent_get() >> >> What do you prefer? >> >> I'm quite OK with the former, but would rather not rewrite the whole of >> EFL twice. :) >> > > I dont like to put functions under the efl_ namespace which are c only > or not guaranteed to exist in the bindings. > > So for example eo_add. Its a function which is c only, putting it under > the efl_ namespace looks like its the "efl" way of creating objects, > which is not true. It depends on the binding, so having there a > namespace which implies "hey thats a c mechanism" would my much sense in > my opinion, and could probebly prevent some confusion. > > So all in all, i would not rename the functions which are part of Eo.h > espacially eo_add, eo_del, eo_isa. > > tl;dr: > I think renaming the content of Eo.h is not good, its c api, > and not meant to be binded automatically by a bindings-generator.
I personally preferred keeping the eo namespace, but that's a whole different matter. I already pointed out a few problems with your approach on IRC, but let me repeat some and point out some new ones. First of all, yes, they are C only, but who cares?! The only people who would *maybe* (not really) get confused by it are people who write both in C and in another language. Even out of these small group, I doubt people will get confused because obj->add() obviously doesn't make sense, and others don't make sense either, so no-one is going to try them and get confused. It doesn't add any *important* information, so no need to encode it in the name. Also, a function being an eo (automatically bindable) function vs non-eo is so arbitrary. eo_del() for example, that you mentioned above is actually in the .eo file nowadays. It never used to be. It could maybe make sense in bindings. You don't know, it depends on the binding. I can't declare something as C only because I don't really know which bindings may need them or may not. So essentially you are sacrificing flexibility, adding confusion for C only people, and making things just a tad more annoying for zero benefits. I strongly disagree with this. -- Tom ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohodev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
