Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:88170 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 35849 invoked from network); 13 Sep 2015 01:24:25 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Sep 2015 01:24:25 -0000 Authentication-Results: pb1.pair.com header.from=francois@php.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=francois@php.net; spf=unknown; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.27.42.6 as permitted sender) X-PHP-List-Original-Sender: francois@php.net X-Host-Fingerprint: 212.27.42.6 smtp6-g21.free.fr Received: from [212.27.42.6] ([212.27.42.6:21082] helo=smtp6-g21.free.fr) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E4/C2-06745-740D4F55 for ; Sat, 12 Sep 2015 21:24:24 -0400 Received: from [127.0.0.1] (unknown [82.232.41.54]) (Authenticated sender: flaupretre@free.fr) by smtp6-g21.free.fr (Postfix) with ESMTPSA id 55A5382211; Sun, 13 Sep 2015 03:16:47 +0200 (CEST) To: Bob Weinand , Sean DuBois Cc: PHP Internals References: <55EE1293.7020404@php.net> Message-ID: <55F4D03D.2050902@php.net> Date: Sun, 13 Sep 2015 03:24:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 150912-5, 12/09/2015), Outbound message X-Antivirus-Status: Clean Subject: Re: [PHP-DEV] strict-api - Proposing a tool to check and enforce encapsulation From: francois@php.net (=?UTF-8?Q?Fran=c3=a7ois_Laupretre?=) 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