On Tue, 17 Apr 2012 09:50:19 +0300 Tom Hacohen <[email protected]> said:
i don't see the point. it's just a pointer to something. it's fine as-is. in this way of doing an api we no longer can use the const attribute to say anything about the object here. there isn't a lot of point either. > Dear, > > One more flaw I found (well actually Daniel found it): > eobj_do accepts "Eobj *" which is obviously not const. This means that > eobj_do will always return a warning when passing const objects to it, > even if we just query it for information, without changing. > This means that working with "cost Eobj *" will not be possible anymore. > > I'm thinking about just adding eobj_query that will accept "const Eobj > *" and will only let you execute "const compatible" operations on it. > What do you think? > > -- > Tom. > > On 02/04/12 12:58, Tom Hacohen wrote: > > Dear, > > > > As some of you may know, my team and I have been working on Eobj, a new > > objecting system for EFL. The current concept of varargs and having > > eobj_do (you'll see what I'm talking about) was suggested to me by > > raster and cedric, but I believe someone else deserves the original > > credit, so please, if you know who I should be giving credit to, let me > > know. > > > > I uploaded my current Eobj code to: > > http://www.enlightenment.org/~tasn/eobj.tgz > > Please feel free to take a look at the "lib" and at the examples in the > > examples dir. This example code uses cmake, because that's what I find > > most comfortable to work with, but the final version will be integrated > > into EFL and will use autotools, or in other words, please don't bother > > commenting about the build system. > > > > It's done and can be integrated into the EFL except for a couple of > > things that are not yet decided: > > 1. Thaw/freeze are not implemented yet > > * Do we want to be able to freeze per object or globally to all > > objects? > > * Do we want to be able to freeze per signal or just the whole > > object? (freezing just per signal can be risky because there might be other > > signals and applications that expect certain signal sequence and failing > > to block all will cause inconsistencies). > > 2. There are still some slow paths - will be fixed as needed. > > 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. > > 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. > > 5. No docs/proper internal naming yet, but API and examples should be solid. > > 6. Currently the order of functions called is: object functions, mixin > > functions and only then, composite object functions - should decide if > > that's what we want. I like it. > > 7. Mixin constructors are not called ATM. > > * Will be fixed. The reason it was not done yet is that MIXINs are > > 2nd rate citizens, as we don't yet have a use for them in the EFL. > > 8. Currently only classes have data, not mixins. - Will be extended. > > * I'm thinking about just letting them use the generic data and make > > the common case faster... > > 9. I plan on adding a signal indicating signal callbacks > > addition/removal. - I.e you'll get a "some registered to 'resize' event" > > signal. > > * Very useful in many cases. > > 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. > > 11. Class type and all of that handling is not yet final. > > * Currently you have a class type of either: > > EOBJ_CLASS_TYPE_REGULAR, EOBJ_CLASS_TYPE_REGULAR_NO_INSTANT, > > EOBJ_CLASS_TYPE_INTERFACE, or EOBJ_CLASS_TYPE_MIXIN. I'm not sure if we > > need more, or if it should be ditched. > > 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. > > 13. Missing a way to group set/get. > > * I plan on making a way to say "set and get both modify the same > > property" which is not yet implemented. > > > > Please comment on the API (either the class API or the actual usage API) > > and especially on the bullets I wrote above. > > > > Please also take a look at the elw_boxedbutton "widget" in the evas > > example which shows the API for handling composited objects. > > > > 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. > > > > There is one noticeable hack in the evas example: the > > eobj_evas_object_set/get functions. They are only there because we don't > > currently use eobj in evas, but will be fixed "automatically" once we do. > > > > Bug reports, comments, suggestions, or whatever are more than welcomed! > > > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
