On 23/04/12 05:15, Cedric BAIL wrote: > 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). >
Already there. Do you like what's there atm? Named weak-refs make no sense and furthermore, weak-refs are not interchangeable with strong-refs, so what you are suggesting doesn't make sense for us. Did you look at the current implementations of weak-ref and named-refs? Do you like them? >> 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). I'm talking about internal sanity checking, I don't see how that'd matter. > >> 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. Yeah, it's in my TODO, somewhere. You have to understand though, it's not a top priority comparing to integration into Evas for example. All the changes in eobj in the last couple of days were to support the integration into evas we are working on at the moment. > >> 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. I already forgot about it. Though seriously, I know, just didn't get to it. > >> 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 ? pre: "we are about to possibly do something"? Sounds unneeded. As for post: "we possibly did something before" - sounds useless as well. Don't you agree? Maybe there are uses for that, but please provide example use cases. > >> 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. Already like that. Well, without the ugly comments. :) > >> 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. Perhaps. I believe having the same name as what we had before is a big advantage (easier for people to "learn"), but I guess I can change it. Lets see what other people think. Thanks for your comments, 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
