Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80129
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.174 as permitted sender)
MIME-Version: 1.0
Date: Sun, 4 Jan 2015 00:42:44 +0100
Message-ID: <CAF+90c8KjgojwgFYDUwMWYk+gv+ENNSncb_oYVf3WJ+ymdv37w@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d043c08b687414d050bc80341
Subject: PHP 7 API naming conventions: str vs string
From: nikita.ppv@gmail.com (Nikita Popov)

--f46d043c08b687414d050bc80341
Content-Type: text/plain; charset=UTF-8

Hi internals!

PHP 7 uses two different string types. One is the ordinary C string char*,
the other is a custom zend_string* structure, which additionally embeds
length and GC info.

We currently have a bunch of APIs that accept either C strings or
zend_strings, but the naming is pretty much random wrt str/string usage.
Examples:

 * The main zend_string API is prefixed with zend_string_
 * The smart string API for zend_strings uses the name smart_str, whereas
the smart string API for C strings uses smart_string. To add insult to
injury in PHP 5 smart_str was the one for C strings.
 * The hash API uses _str to denote APIs that accept C strings instead of
zend_strings
 * ZVAL_STR is used for zend_strings, while ZVAL_STRING is for C strings
 * zend_str_tolower works on C strings, whereas zend_string_tolower is for
zend_strings
 * ... many more

Basically if you have two APIs, one using str, the other using string, you
can't tell which one is for C strings and which one is for zend_strings. It
could be either way.

It would be nice to have a convention for this and stick with it. E.g.
"string" is for zend_strings and "str" for C strings.

Or maybe be more explicit and use "cstr" for C strings. (For symmetry the
zend_string type could become zstr.)

Thanks,
Nikita

--f46d043c08b687414d050bc80341--