Re: strict-api - Proposing a tool to check and enforce encapsulation

Hi Bob, Le 13/09/2015 00:44, Bob Weinand a écrit :

While I don't disagree with the idea of making accidental direct access harder, I see a particular disadvantage for debugging. Nobody will like to write "p fbc->op_array.filename->zstrict_field_zend_string_val" (I hope I got it right?) just to figure out where the targeted op_array is located. [At least lldb only shows one character of the value when just printing the zend_string, due to the struct hack...] Now you may say macro? Well, honestly, I don't usually use macros (as .gdbinit isn't compatible with lldb and lldb is more stable than gdb on OS X) While it brings a minor guarantee that the ZSTR_*() API is really used, it makes debugging much harder; so I prefer to not merge this patch.

I was probably not clear enough : you will *never* debug code configured/compiled in zstrict mode. This mode is reserved for compile-time checks only. Once you have checked that everything compiles fine in zstrict mode, the next step is to 'make clean' and throw the compilation result away. You can 'make test' before, if you want, but you will never distribute nor debug code compiled in zstrict mode. The same with travis: the zstrict flag can be set only because the resulting code will never be distributed nor used for debugging. So, there's no question of debug macro nor .gdbinit. When debugging your code, you'll keep using the usual field names (fbc->op_array.filename->val for instance). Regards François