On 13/04/12 13:17, Carsten Haitzler (The Rasterman) wrote:
> hey tom. some of these i already mentioned to you, but i'll repeat here for
> the
> good of everyone following:
Yeah, I already fixed some of those just after we talked, but thanks. :)
>
> 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. :)
Yeah, done. :)
> 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. :)
Yep.
> 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. :)
Nah, it's a good example. It's trivial to come up with the way to do it
yourself, but having an example that does it exactly is good for people
seeking for the right way of doing stuff.
> 4. aaah varags for list of parent classes... coolio. i was wondering how
> multi-inheritance was going to work.
Yeah. :)
> 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.
I generally agree, but I consider the examples as something people
should copy & paste from, or at least as test cases (I use them like
that atm) so I want them to be cross-platform.
>
> 6. eobj.c could be split into class, base class, obj funcs and callback funcs.
> into 4 files. :)
Yeah, messy inside, I know. :)
> 7. eobj_super_do()... wtf?
I used "super" because that's the common naming for that (it's like that
in python and java among others). It's just for calling the function of
the super-class, or more correctly, the next on in the mro.
> 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) :)
No idea why I ever made it a uintptr_t, WTH. :) Fixed now.
> 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
You are right, fixed.
> 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).
Yeah, never got around to it, will do it when I implement the "id"
system. It's internal anyway...
> 11. eobj_constructor_super() ???? eobj_destructor_super() ?????? pls explain
> :)
Same as #7, it's just a way to call the next function in the mro in the
specific case of the constructors/destructors.
> 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.
Will think about it.
> 13. instead of walking_list in obj - use ref/unref? (as above). 1 less base
> obj
> member too.
Can't. I use it to know when I'm allowed to removed callbacks from the
list of callbacks, the object ref won't help me there.
> 14. ummmmmmmmmmmmmmmmmmmmmm stuff. (sorry drawn a blank here).
It's fine, after 13 bullets, my brain is also nothing more than a
scrambled egg. :)
Ah, damn, I have you second mail to respond to as well ;P
--
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
