On Mon, Dec 5, 2016 at 3:16 PM, Tom Hacohen <t...@osg.samsung.com> wrote: > This is wrong, and as JP and Stefan said, breaks things. First of all, > why add code to the non-debug variation? Also, if you're already adding > to the non-debug variation, why not include it in the commit message? > This is very misleading.
sorry not splitting the commits as very small pieces, but the idea was to check the object since the class was already being checked... the check _is_a_obj() is as check as the class one, so that's why it's out of the EO_DEBUG guards. > Anyhow, as the tests clearly show, efl_super() is also used with class > functions, so it needs to work. The efl_isa() line should work on > classes too (I think), but the is_object is plain-wrong, and definitely > shouldn't be outside the ifdef, but also not inside. It just doesn't > belong there. as above, I'm rather going to add "|| is_a_class()" like done for class than hide it under EO_DEBUG due those reasons. efl_isa() is more expensive, then okay to remain solely on EO_DEBUG. > Furthermore, while I'm all in favour of this test in the eo_debug > scenario, I disagree with the statement in the commit message. If you > have such mistakes you are doing something very wrong, because the > recommended way of using efl_super is with the macro "MY_CLASS" that > should be defined to the current relevant class in the source file in > order to avoid such mistakes as you described... it happens, to start the first time I saw efl_super() was in code generated by eolian, that uses the name, not MY_CLASS... then I reached the c&p errors I said. If you do check my code in git, you see I converted to MY_CLASS once I discovered about it by reading other code. In all cases I'm far from a "n00b" and faced those errors and when I expected the system to be nicer to me, thus I added these errors checks. Also remember that users may have 2+ objects in the same C file and the misuse is even easier... even with the macro as you may naively reorder the code and break, then a proper message like the one with efl_isa() comes to rescue. If we should just blindly trust efl_super() is going to be used properly, then why check for class? that check is what remembered me of my early mistakes and lead to the extra checks on object. -- Gustavo Sverzut Barbieri -------------------------------------- Mobile: +55 (16) 99354-9890 ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
