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