Re: [PHP-DEV] Naming issues, solutions

On Mon, Aug 25, 2014 at 2:59 PM, Pierre Joye <[email protected]> wrote:

>
> On Aug 25, 2014 12:56 PM, "Dmitry Stogov" <[email protected]> wrote:
> >
> >
> >
> >
> > On Mon, Aug 25, 2014 at 2:45 PM, Pierre Joye <[email protected]>
> wrote:
> >>
> >>
> >> On Aug 25, 2014 9:22 AM, "Dmitry Stogov" <[email protected]> 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
>