Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76863
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEZPtU7GidddrExajjgF5GuVQVf4rkxSiHtP+waEw+z9d+UPqA@mail.gmail.com>
References: <CAEZPtU5_Gv+=R26b+wFMuwe6gxPXtKpdgQsaoV=Y0ON+tzfoXg@mail.gmail.com>
	<437C0D23-0519-4EA1-BBEB-A74C7C70A10E@rouvenwessling.de>
	<CAEZPtU7Y6S9U+P_KEOhDJ-g12CihrOmoqFMpQnGUGLhp90r9qA@mail.gmail.com>
	<CA+9eiLu_onnG136CunB8bfAWs--xPwaO70EbeZb3jPwqjrg7Cg@mail.gmail.com>
	<CAEZPtU6DNYh=EtUGGdrM20biZDGuhjGCoYfxwA_Pw3sH6tjj+g@mail.gmail.com>
	<CA+9eiLvYU4eyeW7tZ4j=g6gYZKd8BFJbfBE__dcUqLx9dixdJQ@mail.gmail.com>
	<CAEZPtU7GidddrExajjgF5GuVQVf4rkxSiHtP+waEw+z9d+UPqA@mail.gmail.com>
Date: Mon, 25 Aug 2014 15:14:38 +0400
Message-ID: <CA+9eiLvwrHCqtZCanFGCC_7RijozFLQJAm+ZD8rtS7FTxcst1Q@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: =?UTF-8?Q?Rouven_We=C3=9Fling?= <me@rouvenwessling.de>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1132f2a2eb81640501724aba
Subject: Re: [PHP-DEV] Naming issues, solutions
From: dmitry@zend.com (Dmitry Stogov)

--001a1132f2a2eb81640501724aba
Content-Type: text/plain; charset=UTF-8

On Mon, Aug 25, 2014 at 2:59 PM, Pierre Joye <pierre.php@gmail.com> wrote:

>
> On Aug 25, 2014 12:56 PM, "Dmitry Stogov" <dmitry@zend.com> wrote:
> >
> >
> >
> >
> > On Mon, Aug 25, 2014 at 2:45 PM, Pierre Joye <pierre.php@gmail.com>
> wrote:
> >>
> >>
> >> On Aug 25, 2014 9:22 AM, "Dmitry Stogov" <dmitry@zend.com> wrote:
> >> >
> >> > Hi Pierre,
> >> >
> >> > I'm glad, you agree to rename IS_INT back to IS_LONG.
> >> >
> >> > zend_long and size_t usage looks fine.
> >> >
> >> > I see no problems changing zend_string related API and related macros
> introduced in NG. They are new for everyone.
> >> > I hope, the changes won't make API less clear or useful (so it would
> be great to review them).
> >> >
> >> > I don't see a big reason to rename "zend_uint" into "uint32_t", but
> it's just my own opinion. I would prefer keep it as is, or at worse case
> rename into "zend_uint32" or "uint32". Anyway, I'll agree with majority.
> >> >
> >>
> >> uint32_t :)
> >
> > 3 people are not the majority (or may be I missed discussion on IRC).
> > It's better to think before changing something in many places without a
> real reason.
>
> Why do we need it when the standard type exists and does exactly what we
> want? Same for size_t. It is mostly contained in the engine, no other
> impact and avoid yet another type definition for existing standard type (we
> have php_stdint.h to make them always available).
>
We never had zend_size_t before and used size_t.
but we had zend_uint for ages and changing it to new name in thousand
places won't make a lot of sense.
If you like to make it always be a 32-bit number, just change the
definition.
If you are going to rename zend_uint, should we expect renaming of all the
similar zend_* types from zend_types.h?

typedef unsigned char zend_bool;
typedef unsigned char zend_uchar;
typedef unsigned int zend_uint;
typedef unsigned long zend_ulong;
typedef unsigned short zend_ushort;

Thanks. Dmitry.

 >> > How are we going to proceed?
> >> > Do you like voting in
> https://wiki.php.net/rfc/better_type_names_for_int64 or you may just
> revert part of the int64 patch related to IS_LONG -> IS_INT renaming?
> >>
> >> We will just do the changes listed in the initial mail. The sooner the
> better. Anatol or I will do it. It should be ready by Wednesday. If we can
> avoid a 2-3 weeks delay let not do the rfc. As these changes match what was
> discussed and fit with the majority (subjective part as only the vocal
> ones), we should not see any objection. We will simply apply it on
> Wednesday if nobody complained.
> >
> > Agree, we need it ASAP.
> > I'll try not to commit anything big to not make you additional troubles.
> >
> > Thanks. Dmitry.
>
> Thanks
>
> Cheers,
> Pierre
>

--001a1132f2a2eb81640501724aba--