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

> Am 13.09.2015 um 03:24 schrieb François Laupretre <francois@php.net>: > > 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 Well, that either just makes workflow unnecessarily complex or many devs just won't care too much about it… and these who do may be annoyed to fix others code before it's useful for themselves... (Also, I don't think like some devs will be particularly eager to recompile before each push … it doesn't take just one minute on every machine) Additionally, extension devs… They'd have to switch target php install while coding, just to check against zstrict install and no zstrict. Well… that just begins to become insane. Sorry, but making zstrict optional is just plain annoying of developers... Bob