Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76849
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.179 as permitted sender)
MIME-Version: 1.0
Sender: laruence@gmail.com
In-Reply-To: <CAEZPtU5_Gv+=R26b+wFMuwe6gxPXtKpdgQsaoV=Y0ON+tzfoXg@mail.gmail.com>
References: <CAEZPtU5_Gv+=R26b+wFMuwe6gxPXtKpdgQsaoV=Y0ON+tzfoXg@mail.gmail.com>
Date: Sun, 24 Aug 2014 20:34:37 +0800
Message-ID: <CABBJUpevo+JyCB0X1ddG_uxuAWOkN-U+oZzhtyN2+0OsxXdfTw@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Naming issues, solutions
From: laruence@php.net (Laruence)

Hey:

On Sun, Aug 24, 2014 at 8:30 PM, Pierre Joye <pierre.php@gmail.com> wrote:
> Hi,
>
> Nikita, Xinchen and I have sit down together this morning to solve a
> couple of naming issues, those having
> caused some flames, trolls and FUDs in the last couple of days. The
> good news is we have found a consensus
> that solves our concerns, consistency and reduce the amount of changes
> in existing code.
>
> Please not that this mail is not my personal taste or wishes, but the
> results of a refreshing, constructive
> and good discussions with Xinchen and Nikita earlier this morning.
>
> Summary:
> zend_uint     > int32_t
> zend_size_t   > size_t
> zend_int_t    > zend_long
> IS_INT        > IS_LONG
> Z_IVAL        > Z_LVAL
> Z_STRSIZE     > Z_STRLEN
> zend_str_*    > zend_string_*
> STR_* macros  > droped
>
> Details:
>
> We have a header available by default to define c9* stdint, see
> main/php_stdint.h. This header ensures
> consistency accross platforms and that the size of each type is
> correct. It is important to keep
> that in mind while reading the rest of this mail.
>
> * zend_uint
> zend_uint is used exclusevely in the engine (maybe some debugger or
> engine related extensions) and has been around for a while. We like to
> drop it and use int32_t instead anywhere where zend_uint is used.
> Using int32_t is good because this will ensure that we use the correct
> type even on ILP64 - zend_uint  would currently totally blow up on
> those systems.
>
> *zend_size_t
> Given that size_t is a standard type, adding zend_size_t makes little sense.
>
> * zend_int_t, zend_long, IS_INT/IS_LONG
> One of my main concerns is consistency between APIs and macros names
> and the underlying types.  A solution to this problem was quite
> obvious (only not on Friday ;). zend_int_t will be renamed  to
> zend_long, IS_INT and Z_IVAL will renamed to their old names, IS_LONG
> and Z_LVAL, respectively.
>
> * Strings
> First change, Z_STRSIZE will be renamed to Z_STRLEN (old name). We
> also like to drop STR_ macros and  rely directly on the zend_string_*
> APIs. While doing at it the zend_string APIs will be prefix
> zend_string and not zend_str_* as it is now, for the same reason:
>
> During the NG works and the ports of many extensions, numerous bugs
> appear due to bad usage  of STR_* macros with either char* or other
> char/string related types. Making the name more obvious  will help.
>
>
> PS: IRC log available if anyone likes to double check it, #php.pecl
thanks.

I am glad we have reach a agreement here. actually to me, the naming
issue has blocked me to start porting work on my own exts, so if no
objections, I'd like to see it settled down and commit to trunk asap
:)

thanks
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/