Re: [PHP-DEV] [RFC] Better type names for int64 RFC

On 8/22/14, 11:38 AM, Pierre Joye wrote:
> On Aug 22, 2014 5:33 PM, "Andrea Faulds" <[email protected]> wrote:
>>
>>
>> On 22 Aug 2014, at 12:16, Nikita Popov <[email protected]> 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 the
>>> 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’m very much in favour of this RFC. It is not necessary to change the
> type names after all; if people turn on compiler warnings, they’ll find out
> what’s broken anyway.
> 
> 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
...
#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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iEYEARECAAYFAlP39u0ACgkQlxayKTuqOuDTGwCfYbrtFtFE2ubaywWRinBJ8IDb
PeEAnjbBYZxPXj7BxwETs7b7hx0E8EVV
=3xND
-----END PGP SIGNATURE-----