On 13/04/12 14:02, Carsten Haitzler (The Rasterman) wrote: > On Mon, 02 Apr 2012 12:58:21 +0300 Tom Hacohen<[email protected]> said: > > i have some more things as my brain churned that i didn't add to my previous > mail: > > 15. eobj_generic_data_* ... i really think this should support passing in a > free func for generic data (NULL == dont free it), and previous egenric data > is > auto-greed if u set new data on top, same when u del - dont bother returning > the pointer to it except on get. ALSO for generic data - can u provide a TYPE > param - string, opque, eobj, opaque list, object list etc. types. opaque is > unknown to eobj, but string can be used to account for memory objects and eobj > can be used to have eobj auto unref attached generic data if its another eobj > or list of eobj's. this would come it very handy.
I thought about it, but it felt a bit fat to me... The problem is that we'd have to save a free function/NULL for every property which is kinda wasteful. Especially since you can in most cases just have a delete callback and free the properties from there. If you really think it's a must, I'll add it. > 16. eobj_event_callback_add() can be a macro imho. :) Done. > 17. maybe we can shorten callback to cb for brevity, also other full words > might be shorter? opinions? save typing? generic_data -> gdata? ... Perhaps, we just need to decide on better naming. :) > 18. ok so we have callbacks that are of course called in-line in the stack. > i'm > mulling over if we should use the same callback system to POST events > (messages) on a queue and then to be able to process them later as part of the > ecore event loop. you will have to register a message queueing func with eobj > - but eobj can handle reffing the target obj whenever u pose a msg cb and > unreffing when msg event is finished in the queue. this can definitely help > out > here. now the obj can choose if it wants to call cb's inline or defer on the > event queue... :) in fact this can even get quite smart - if in the mainloop > it > queues, if from a thread.. it can use the ecore async infra to send the cb's > to > the mainloop as messages... oooh baby... :) The biggest advantage (and it's really big in my pov) with inline callbacks is that you don't have to allocate data on the heap for the event info, you can just allocate data on the stack. It's a big save code-wise, and I'm certain performance-wise as well. If you make it "dynamic" i.e decided by eobj, you'd have to allocate the data (as the callback call my be deferred) which is annoying. Also, signals in many cases cause resizes of other objects and deferring those means the code we write won't be able to get the up to date info, which is also annoying... > 19. and speaking of threads... i am wondering if maybe.. just maybe... we > might > not want to provide some locking/unlocking infra for eobj? it probably needs > to > handle recursive locks WITHIN the same thread... :/ let the flames begin! Nah. :) > 20. pants on. Never! Thanks for reviewing. If you can, please also reply to the questions I asked in my first (and second?) posts. For example what I said about the "flush" function that we talked about the other day, but not only... -- Tom. ------------------------------------------------------------------------------ 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
