Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76759
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <6E03BE65-260C-4B94-9587-C785FBC112C2@ajf.me>
References: <CA+9eiLt7-a9vA-s2b7KymFLkGvFEW5rXJV5n3pMmkS+xxU6-qQ@mail.gmail.com>
	<6E03BE65-260C-4B94-9587-C785FBC112C2@ajf.me>
Date: Thu, 21 Aug 2014 19:56:09 +0200
Message-ID: <CAEZPtU6ADFRd4JekU_PuCNWAZHN3y28tNR-9XUmJ+qnGOn8T7Q@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP internals <internals@lists.php.net>, Dmitry Stogov <dmitry@zend.com>, Anatol Belski <ab@php.net>
Content-Type: multipart/alternative; boundary=001a1134b0047ee4fd0501276f85
Subject: Re: [PHP-DEV] 64-bit integers and 64-bit string length patch is ready
 to be merged
From: pierre.php@gmail.com (Pierre Joye)

--001a1134b0047ee4fd0501276f85
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Aug 21, 2014 7:42 PM, "Andrea Faulds" <ajf@ajf.me> wrote:
>
>
> On 21 Aug 2014, at 18:23, Dmitry Stogov <dmitry@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=E2=80=99t like this. With the bigints patch and RFC, I want to keep=
 IS_LONG
and the word =E2=80=9Clong=E2=80=9D to distinguish between what would be th=
e 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 =E2=80=9Cinteger=E2=80=9D and =E2=80=9Cint=E2=80=9D are synonyms fo=
r =E2=80=9Clong or bigint=E2=80=9D. However, if
internally an int is one thing and to userland it=E2=80=99s another, that w=
ould be
problematic. If this goes through, I=E2=80=99d probably make my bigints pat=
ch
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=E2=80=99s actually a C `long long`
underneath, isn=E2=80=99t 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

--001a1134b0047ee4fd0501276f85--