Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76825
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.220.45 cause and error)
Message-ID: <53F7F6ED.1050609@lerdorf.com>
Date: Fri, 22 Aug 2014 19:05:33 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Pierre Joye <pierre.php@gmail.com>
CC: PHP internals <internals@lists.php.net>, 
 Nikita Popov <nikita.ppv@gmail.com>
References: <CAF+90c_AMJ3SLyX7eDQq-gwFLOCQUfLus+qFfJgAgTzBpZpfEg@mail.gmail.com>	<D19D208D-06E9-4310-92DD-6F02C666138C@ajf.me> <CAEZPtU7yMbMSoB2imCH8NX7nCwXttpnf878vJeBK2UypJ_QxVQ@mail.gmail.com>
In-Reply-To: <CAEZPtU7yMbMSoB2imCH8NX7nCwXttpnf878vJeBK2UypJ_QxVQ@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="HhrWCUE1ew8MGSXvxB41npSWcfsit0rSK"
Subject: Re: [PHP-DEV] [RFC] Better type names for int64 RFC
From: rasmus@lerdorf.com (Rasmus Lerdorf)

--HhrWCUE1ew8MGSXvxB41npSWcfsit0rSK
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 8/22/14, 11:38 AM, Pierre Joye wrote:
> On Aug 22, 2014 5:33 PM, "Andrea Faulds" <ajf@ajf.me> wrote:
>>
>>
>> On 22 Aug 2014, at 12:16, Nikita Popov <nikita.ppv@gmail.com> wrote:
>>
>>> As we were not given a chance to resolve this issue before the merge,=
 a
>>> short proposal has been created, which aims to revert all unnecessary=

>>> naming changes and instead use type names that are consistent with th=
e
>>> existing code base and expectations:
>>>
>>>    https://wiki.php.net/rfc/better_type_names_for_int64
>>>
>>> Due to the unexpected merge on short notice, with no chance for
> discussion,
>>> this issue is blocking a number of other patches. As such I ask if we=

> can
>>> move through this RFC with a shortened cycle. I would not appreciate
> having
>>> to wait three weeks to have a workable codebase again.
>>
>> I=E2=80=99m very much in favour of this RFC. It is not necessary to ch=
ange the
> type names after all; if people turn on compiler warnings, they=E2=80=99=
ll find out
> what=E2=80=99s broken anyway.
>=20
> That's one of my points. They won't for all cases. And why good names
> reflecting the underlying type will help. It is what the 1st version if=
 the
> int64 rfc did.

The end result here is likely that in order to write a portable
extension, extension authors will simply do:

#ifndef IS_LONG
# define IS_LONG IS_INT
# define Z_STRLEN Z_STRSIZE
# define RETURN_LONG RETURN_INT
# define RETVAL_LONG RETVAL_INT
# define Z_LVAL Z_IVAL
=2E..
#endif

and not change a single macro anywhere in the actual code.

That's certainly what I would do. And if the current naming survives we
should provide a macro_compat.h file with the complete set.

Overall I don't think trying to make the macro names match the
underlying types exactly is worth the hassle here. Our audience for this
is extension authors. In most cases the author doesn't necessarily care
about the subtle differences between calling it IS_LONG and IS_INT and I
don't think it actually makes it any more clear to a C developer. "int"
is not a well-defined cross-platform type anymore than a "long" is. So
we are swapping one set of vague names for another set of vague names.
I'd much rather see a nice clear README.TYPES or perhaps it is simply
part of the existing README.PARAMETER_PARSING_API which defines exactly
what these various macros mean.

-Rasmus


--HhrWCUE1ew8MGSXvxB41npSWcfsit0rSK
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iEYEARECAAYFAlP39u0ACgkQlxayKTuqOuDTGwCfYbrtFtFE2ubaywWRinBJ8IDb
PeEAnjbBYZxPXj7BxwETs7b7hx0E8EVV
=3xND
-----END PGP SIGNATURE-----

--HhrWCUE1ew8MGSXvxB41npSWcfsit0rSK--