Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66915
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAESVnVr_jLwRbVsOOx3urPv0Qzc9Rc-7y2CNp1T0mH+8ad3cRg@mail.gmail.com>
References: <CAESVnVr_jLwRbVsOOx3urPv0Qzc9Rc-7y2CNp1T0mH+8ad3cRg@mail.gmail.com>
Date: Wed, 3 Apr 2013 15:31:18 +0200
Message-ID: <CAF+90c9N81ZoSpwm2hSh=gCYV2Y3jB1e+N4_N_d_QfHk9JPK5g@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d04479faf719dbe04d974ded6
Subject: Re: [PHP-DEV] [RFC] Simplified Array API for extensions
From: nikita.ppv@gmail.com (Nikita Popov)

--f46d04479faf719dbe04d974ded6
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Apr 3, 2013 at 4:52 AM, Sara Golemon <pollita@php.net> wrote:

> https://wiki.php.net/rfc/php-array-api
>

I like the idea behind this, though right now that API seems a bit like a
combinatorial explosion of functions and I think it would be better if one
could separate different parts of it.

So some feedback:

1. The list of type modifiers seems excessive and the single-character
shorthands are confusing (especially as this particular set doesn't seem to
be employed anywhere else in our APIs). So some particular suggestions:

  a) The "c" modifier seems like an unnecessary microoptimization.
Compilers should be able to optimize strlen() calls on constant strings
away and even if they didn't, it wouldn't be much of a big deal. Also using
the "c"-variants on a non-literal would not throw an error and just use an
invalid length instead.

  b) Imho the "l_safe" case does not need its own modifier. Typically
strings in PHP are always zero-terminated (in debug mode you'll actually
get warnings if they are not). The cases where they aren't zero-terminated
are rare and in these cases one can just write those two extra lines of
code to do the right thing.

  c) I think it would be a lot more intuitive if we used the terminology of
the normal array APIs instead of the shorthands:

    php_array_fetch => php_array_fetch_assoc
    php_array_fetchl => php_array_fetch_assoc_ex
    php_array_fetchn => php_array_fetch_index
    php_array_fetchz => php_array_fetch_zval

2. The php_array_fetch*_* APIs currently combined two things: a) Fetching
from the array and b) Casting it to some type. I think both should be
separate. Not only to avoid the combinatorial explosion of different
modifier+type combinations, but also because those casting methods are also
applicable to other contexts, not just arrays casts. I asked some time ago
to add functions that can directly get a long/double from a zval (though
didn't pursue this further). Your APIs add something like that, but tightly
coupled to array fetches. There would be more use for it if it were
separate :)

Thanks,
Nikita

--f46d04479faf719dbe04d974ded6--