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

On Sun, Sep 13, 2015 at 03:24:13AM +0200, François Laupretre wrote: > 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 > That sounds good to me! That would double build times though, is that going to be a concern? This won't hurt development time though, since you would dev in zstrict, and then switch to non-zstrict when running/testing? A +1 for me would be to find a helpful way to tell extension developers what the 'proper form' would be. So if I do a (zend_string *) foo->val I would be hinted to the proper API. Another +1 would be warnings for an entire code base, hopefully the build doesn't just bail on the first error/file a lot of 'bug fixing' development depends on stuff like syntastic.