Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88173
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.82 as permitted sender)
Message-ID: <BLU436-SMTP233C9B453FF355D989D96C5E25E0@phx.gbl>
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
In-Reply-To: <55F4D03D.2050902@php.net>
Date: Sun, 13 Sep 2015 10:41:09 +0200
CC: Sean DuBois <sean@siobud.com>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
References: <55EE1293.7020404@php.net> <BLU436-SMTP2006B293CD9B4C9979A627BE25F0@phx.gbl> <55F4D03D.2050902@php.net>
To: =?utf-8?Q?Fran=C3=A7ois_Laupretre?= <francois@php.net>
Subject: Re: [PHP-DEV] strict-api - Proposing a tool to check and enforce encapsulation
From: bobwei9@hotmail.com (Bob Weinand)

> Am 13.09.2015 um 03:24 schrieb Fran=C3=A7ois Laupretre =
<francois@php.net>:
>=20
> Hi Bob,
>=20
> Le 13/09/2015 00:44, Bob Weinand a =C3=A9crit :
>> While I don't disagree with the idea of making accidental direct =
access harder, I see a particular disadvantage for debugging.
>>=20
>> 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)
>>=20
>> 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.
>=20
> 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.
>=20
> The same with travis: the zstrict flag can be set only because the =
resulting code will never be distributed nor used for debugging.
>=20
> 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).
>=20
> Regards
>=20
> Fran=C3=A7ois

Well, that either just makes workflow unnecessarily complex or many devs =
just won't care too much about it=E2=80=A6 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 =E2=80=A6 it doesn't take just one minute on =
every machine)

Additionally, extension devs=E2=80=A6 They'd have to switch target php =
install while coding, just to check against zstrict install and no =
zstrict. Well=E2=80=A6 that just begins to become insane.

Sorry, but making zstrict optional is just plain annoying of =
developers...

Bob=