On Mon, Apr 2, 2012 at 6:58 PM, Tom Hacohen <[email protected]> wrote: > 3. I'm still uncertain about ref/unref + weak-ref + named-ref. > * I'm not sure yet about which kinds of refing we want. I'm pretty > certain we want named refs and "object" name refs (i.e linking between > objects). And I do believe we need weak ref/unref, but again not yet > decided.
I am all for weak ref and named ref. You should by the way fix the weak ref to remember file and line of their allocation, that would help for debugging. Weak ref could have a debug and production mode. It could in production just be referencing up the EObj and returning a pointer to EObj, but in debug build it would allocate a weak reference. This means we don't need ref/unref in my opinion (You already know I am highly against those). > 4. Many cases are not checked for validity and are just allowed. I plan > on having 2 modes, one for checking those, and the fast mode that will > just be fast. Possibly by having a compilation option + env var to turn > the checks on. I am not sure the env var would be practical in all case (due to inline for example and change in behaviour). > 5. No docs/proper internal naming yet, but API and examples should be solid. It would be nice to have a document that explain the design and idea. Including what _super (And why it is not named warp10 as it should be), what composite means, what are our goal, why we did redesign our own object model, and stuff like that. > 10. Static class method IDs will be added soon. > * Raster suggested a cool idea that will help speed things up, which is > static IDs. It's not done yet, but it's 99% supported. Don't also forget to use eina_mempool. I will go after repacking algorithms when you are done. > 12. Missing a flush function after eobj_do. - I plan on adding a "flush" > (I need a better name) function that will be called at the end of > eobj_do automatically. This will let us defer changes in an easier manner. > * I'm not sure about this one. In one hand, it makes it easier to defer > changes, though on the other, it's deference is not optimal, would have > been better to just create an infrastructure that will let us do better > deference of changes. What about a pre and post signal emitted when we start a _do command ? > Also, we are also working on automatic eobj bindings generation for > other languages, so if you have anything to comment on this matter as > well, please do. I see this as one of the most important parts of this > change. Hum, I have a very stupid things to say here. Would it be possible to generate bindings at compile time and not at runtime ? Performance wise it's a much better option and it would make scripting on good speed track. I don't know how you plan to do this bindings generation, but if you start from a file description, maybe it could also generate the .c/.h file and just put some nice /* *** EOBJECT GENERATOR : YOU CAN EDIT CODE BELOW THIS LINE *** */, /* *** EOBJECT GENERATOR : YOU SHOULDN'T TOUCH THE LINE BELOW *** */. Just trowing an idea here. > Bug reports, comments, suggestions, or whatever are more than welcomed! Just another comment, eobj_event_callback_del_full and eobj_event_callback_del. I would just make eobj_event_callback_del_full be eobj_event_callback_del and rename eobj_event_callback_del as eobj_event_callback_del_lazy. Reason, is that we should encourage the use of the full version (it should really have been our only version since day one, sadly we didn't had it when we did our first release, so it was added to late). Now that we have a chance to fix that, better take it ! That's all I could think about that really matter. -- Cedric BAIL ------------------------------------------------------------------------------ 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
