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