On Fri, Apr 13, 2012 at 12:45 PM, Carsten Haitzler <[email protected]> wrote: > On Thu, 12 Apr 2012 16:44:46 +0200 Jorge Luis Zapata Muga > <[email protected]> said: > >> Hello Tom, >> >> I haven't checked the code completely yet, don't have much time. Nice >> initiative to share the development process, does not happen very >> often ... but could you please share the "design decisions" you take >> with this new OO approach? (Not from a code POV). > > well i can answer that. we have a poor-mans object model up in the evas layer > - > evas object + smart objects. this of course is limiting and doesnt cover > things > like ecore (timers, animators and other things), and is definitely way too > heavy for such things as u need actual evas objects. it also is relatively > limited. > > over the years we have grown a kind-of object model here and many different > mechanisms to have callbacks called on objects. there are ecore event handles, > evas object event callbacks, evas smart callbacks, edje signal callbacks, edje > message callbacks... way way way too many different ways to "get called when > an > event happens" each with different prototypes u have to keep looking up. there > is a lot more besides, and then there is elementary which is in dire need of > multiple inheritance for several situations. in addition we have no current > way > to indirect object lookups to allow for compaction and crash protection. the > point of this is to fix all of that in a simple base object system that also > compacts our code and makes it easier to write and maintain, allows for better > optimisation and cuts the costs of function entry that we currently have in > doing magic type checks every func call etc. - we can amortise than now over > multiple operations. also now string parent/child relationships so child > object > get deleted when parent objects go away etc. but this happens all the way at > the bottom of the efl stack. not up in evas or elm land.
yes, true, is kind of complex to manage all such events, signals and objects on different libraries, but i suppose that if Elm would have been decided to build on top of such libs and not be part of the libs, i mean, hide evas, edje and ecore behind it, then this situation might be simpler to solve. dont want to sound like trolling here, but etk (maybe ewl too, dunno about it), did exactly that, someway it cloned the gobject system and managed to hide all the internals of the different core libraries, but it was doomed by the fact it wasnt using Evas_Objects (or smart objects) as its main object abstraction, but now such object system is required. > >> I'm asking because from the above comments you just explain what is >> *missing* on your implementation, but given that I started some years >> ago a project called "ekeko" (I think it is still under PROTO) which >> wanted to solve this problem too and recently I've been developing >> "ender" (which for me fits exactly on my OO needs), we might be >> sharing several goals, or maybe not ;) > > ender is close, but it's string based properties don't handle actual method > calls, and the strings hurt here. nice for higher up in the stack, but lower > down it will hurt performance-wise. that's not accurate. ender does have, as you pointed out, a string based property system and you have functions to interact with the properties of an object using strings, like: ender_element_value_set(Ender_Element *e, const char *name, ...); which will imply a string -> property lookup, but you also have the simplest forms: ender_element_property_value_set(Ender_Element *e, Ender_Property *prop, ...); which receives the property directly and no need for a lookup, is just a matter to export on your lib such Ender_Property in a similar way that ecore exports its events, i.e extern Ender_Property * OBJECT_ID_PROP; but, beside the question if ender fits here or not, im wondering if the OO system is really needed as the base to build the core libraries on top of it, I mean, given that Evas already has a kind-of-object sytem, Ecore has the same thing with its events and different sub systems, etc, or is better to wrap the already coded core libraries into something more manageable from an application POV. But i guess here that the real problem is Elm and its nature to be Evas Objects. > > so goals are: > > 1. unify callbacks into a single prototype > 2. unify ref/unref/delete etc. > 3. allow for multiple inheritance as well as single > 4. break out the varargs to be able to cut the cost of object checks > (magic/null etc.) over multiple operations all in 1 go > 5. allow for greater object optimisations so you can create an object AND set > all its initial state in 1 function call and thus avoid lots of needless state > transitions as you set things up. its a much more compact way of doing > freeze/thaw without the footwork > 6. put in the layer to allow for object indirection so object pointers can > become not just a pointer to the obj memory, but a double-indirect (obj **) OR > even an ID lookup in a table which can allow for complete safety and zero > crashes in object access. as more safety here comes with more overhead - our > varargs fun lets us spread that cost out over maybe 3, 5 or 10 calls, > ultimately actually lowering our costs below what we currently have in efl. > > bonuses: > 7. we get some method introspection while we're at it > 8. we get callback/signal documentation too from the base up (not just smart > callbacks on evas objects) > 9. object indirection allows for memory compacting to kill off a lot of the > fragmentation i have seen crop up in apps (like e17) over time as it runs. > 10. much better tracking of references > sure, but the above are the goals that every OO system wants, and from the list, why not picking up gobject directly? and dont invest time on doing yet another object system? Something wrong with gobject? (beside the fact that it begins with 'g' of course ;)) > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) [email protected] > ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
