On Aug 21, 2014 7:42 PM, "Andrea Faulds" <a...@ajf.me> wrote: > > > On 21 Aug 2014, at 18:23, Dmitry Stogov <dmi...@zend.com> wrote: > > > The only thing that I don't like is a massive renaming described here > > https://wiki.php.net/rfc/size_t_and_int64_next#semantical_macro_renamings > > > > IS_LONG -> IS_INT > > Z_LVAL -> L_IVAL > > etc > > > > On one hand using INT may be more consistent, on the other hand it's going > > to break habits and make addition headache for merging from php-5 (I know, > > phpng already made problems) > > I don’t like this. With the bigints patch and RFC, I want to keep IS_LONG and the word “long” to distinguish between what would be the two types of integer: > > * IS_LONG/long - 32-bit or 64-bit integer (machine-dependant) > * IS_BIGINT/bigint - arbitrary-size integer > * IS_BIGINT_OR_LONG/integer - either a long or a bigint (pseudo-type) > > Replacing IS_LONG with IS_INT kinda ruins my naming scheme. The intention is that “integer” and “int” are synonyms for “long or bigint”. However, if internally an int is one thing and to userland it’s another, that would be problematic. If this goes through, I’d probably make my bigints patch rename IS_INT to something new again, probably IS_SMALLINT or even back to IS_LONG. > > If it must be renamed, could it be something else? IS_LONGLONG perhaps? Seems stupid on the face of it, but it’s actually a C `long long` underneath, isn’t it? FWIW, I prefer Z_LLVAL to Z_IVAL.
The original patch used the right naming based on the type used behind it. In any case, the patch represents what the rfc and the discussions around it say. I rather merge it asal and begin on the (long) list of todos for 7. If you like to propose new naming with the bigint rfc, please go ahead. Time is also an issue as ppl are beginning to migrate their extensions to test. Changing them again takes time. Cheers, Pierre
