On Mon, Apr 2, 2012 at 11:58 AM, Tom Hacohen <tom.haco...@samsung.com> 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!
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). 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 ;) Regards > > -- > Tom. > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ------------------------------------------------------------------------------ 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
