On Fri, 14 Jun 2013 11:02:36 -0300 Felipe Magno de Almeida <[email protected]> said:
> Hello, > > On Fri, Jun 14, 2013 at 10:16 AM, Carsten Haitzler > <[email protected]>wrote: > > > On Fri, 14 Jun 2013 14:54:24 +0200 Jérémy Zurcher <[email protected]> said: > > > > > Hi, > > > > > > I'm still adding my bits to _eo_class_mro_add, > > > the end is near. > > > > > > What do you think should be done, > > > change a few, bin all , zillions or 1 phab rev, merge like a cowboy ?? > > > > actually... i'm more curious... you jumped in on eo pretty quickly after > > it hit > > git... what do you think about eo in general? good/bad? before we start > > building our universe around this... are there any really nasty things we > > should fix before they are set in stone to retain api/abi? what could be > > done > > to improve it and take it further over time to help people more? > > > > I'm using metaprogramming in C++ for binding to Eo, but it is proving very > difficult for lack of void* data parameters for class functions, e.g., > class_constructor, > class_destructor, constructor. Also, see below. more details? > > so ultimately i expect to have this: > > > > eo_do(obj, > > efl_color_set(255, 128, 0, 255), > > efl_font_set("Sans", 16), > > efl_text_set("This is some text"), > > efl_geom_pos_set(20, 30), > > efl_visible_set(1)); > > > > Eo as is being used, seems to heavily promote lower case macros. I find > this to > be very disturbing. I don't know how this could be workedaround, but > creating > lower-case macros for every function is bound to create difficults with > interoperability of third-party code. i think you are taking the macros too literally - they are lowercase because they actually represent functions (methods). they won't conflict because they are namespaced anyway... as much a conflict as a function call of the same name would be. > > maybe? well for sure so you don't need to now know if its evas_ or edje_ > > or elm_ > > or ecore_ etc. as namespace... just call something obvious on the object > > and > > presto. all these interfaces need to be defined based on looking at > > current efl > > and finding all the design patterns and turning them into common interface > > classes. > > > > keeping in mind that eo is not about replacing c++ but just bringing some > > of > > the convenience of classes, interfaces and inheritance and methods to c, > > as well > > as unifying our callback systems into a single one, making it easy to glue > > objects together and have them auto deleted as a group. and of course > > providing > > a safety barrier to separate apps and tools outside of efl with efl itself. > > for now the eo id / table lookup is the layer we have, with it being mmaped > > outside of normal libc malloc space so its hard to overwrite it. your > > madvise > > stuff you put in so quickly was awesome btw, but over time i'd like to see > > us > > also move more allocation for the insides of objects off into special > > memory > > regions to improve this safety. the eo multi-call varags system lets us > > increase this overhead with the eoid indirect lookup but then amortize that > > cost over multiple calls, thus keeping us at an efficient level even with > > the > > added work. > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) [email protected] > > > > Regards, > -- > Felipe Magno de Almeida > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
