On Mon, 02 Apr 2012 12:58:21 +0300 Tom Hacohen <[email protected]> said:
hey tom. some of these i already mentioned to you, but i'll repeat here for the
good of everyone following:
1. eobj_data_get() inside the method funcs - please just pass the object class
data as a pointer to the func - figured out in the handler parent as its more
efficient. :)
2. passing "op" i think has dubious value. it allows you to implement multiple
methods using a single function (and switch internally based on op id), BUT i
think this is rare at best or not needed. frankly slapping __UNUSED__'s all
thru these funcs is just going to be noisy and pointless. :)
3. in examples/access... protected really is a pointless complication. it's
private data and just as visible and modifiable as any other private data. :)
4. aaah varags for list of parent classes... coolio. i was wondering how
multi-inheritance was going to work.
5. just as examples, it might be nicer to use named field filling eg:
static const Eobj_Class_Description class_desc = {
.name = "Mixin",
.type = EOBJ_CLASS_TYPE_MIXIN,
.ops = EOBJ_CLASS_DESCRIPTION_OPS(&MIXIN_BASE_ID, op_desc,
MIXIN_SUB_ID_LAST),
.events = NULL,
.data_size = 0,
.constructor = _constructor,
.destructor = _destructor,
.class_constructor = _class_constructor,
.class_destructor = NULL
};
in fact for 0's or NULLS, just leave them out so its easier to read:
static const Eobj_Class_Description class_desc = {
.name = "Mixin",
.type = EOBJ_CLASS_TYPE_MIXIN,
.ops = EOBJ_CLASS_DESCRIPTION_OPS(&MIXIN_BASE_ID,
op_desc, MIXIN_SUB_ID_LAST),
.constructor = _constructor,
.destructor = _destructor,
.class_constructor = _class_constructor,
};
it's easier to see the field name so u know what it is meant to be used for,
and skipping "unused" things leads to less cruft to sift through.
6. eobj.c could be split into class, base class, obj funcs and callback funcs.
into 4 files. :)
7. eobj_super_do()... wtf?
8. why is Eobj_Op a uintptr_t? not just an int? any good reason? varargs does
take care of this for us... ? (and by that same token eobj_do should terminate
with a: (Eobj_Op)0, not NULL) :)
9. imho u want to eobj_ref() and eobj_unref() inside many funcs like eobj_do_()
to keep a refcount as long as the func is doing things with the obj
10. missing the abstraction funcs/macros to "get me the real object pointer
from Eobj *obj". eg treat it as an id and look up in a table... or as
a double-pointer etc. :) either way - an abstraction there to sanity check the
obj ptr and get the REAL obj ptr from it. (theoretically that can be compiled
into a NOP to just hand u the ptr as-is - but in real life it will be doing
footwork to do indirect lookups as crash prevention).
11. eobj_constructor_super() ???? eobj_destructor_super() ?????? pls explain :)
12. eobj_event_callback_*() - cool. i now raise the spectre of MAYBE supporting
closures. what in gods green earth would be a closure here? well it would just
be a callback WHERE maybe we manage the func data for the app OR we add another
"environment" param. such an environment sould need to be freed for the app
when cb is deleted (or obj is deleted that cb is on) and any objects references
from this environment automatically get reffed when added as a cb or unreffed
later. how to achieve this - not sure. some way to declare the create the
environment struct and declare what inside of it may be an object handle? this
of course leads to uglies like lists, hashes or arrays of objects.. and we
begin to look like eet... anyway - i'm just bringing this up as a possible topic
of discussion.
13. instead of walking_list in obj - use ref/unref? (as above). 1 less base obj
member too.
14. ummmmmmmmmmmmmmmmmmmmmm stuff. (sorry drawn a blank here).
:)
> 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!
>
> --
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) [email protected]
------------------------------------------------------------------------------
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
