Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66920
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.220.48 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <515BE3F6.4010304@sugarcrm.com>
References: <CAESVnVr_jLwRbVsOOx3urPv0Qzc9Rc-7y2CNp1T0mH+8ad3cRg@mail.gmail.com>
	<515BE3F6.4010304@sugarcrm.com>
Date: Wed, 3 Apr 2013 09:55:18 -0700
Message-ID: <CAESVnVrCPDN3mGAv5JL9Cg2VSibHvc7AA=QrJ9eMOV_=GMkW6g@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] [RFC] Simplified Array API for extensions
From: pollita@php.net (Sara Golemon)

> Nice API, I am a bit worried though about conversion routines.
> Specifically, php_array_zval_to_double() uses different conversion
> algorithm than PHP's standard zval to double conversion, which may
> result in different results in edge cases. Also, these functions seem to
> duplicate existing conversions - we already have code that converts
> zvals to anything, couldn't we reuse it? BTW, it's not completely clear
> what these conversion functions have to do with arrays - why they are
> prefixed with php_array_*? If they aren't meant to be used directly,
> maybe prefix them with __ or something? And if they are, maybe we need
> better names for them...
>
Yeah, they're not meant to be called directly, just meant to be helpers.

> In php_array_zval_to_array() the comment says "If the value is an array,
> then that zval is returned, otherwise NULL is returned." but the code
> says (zarr && (Z_TYPE_P(zarr))) ? zarr : NULL; which means if zarr is
> anything but NULL, it would be returned, regardless if it's array or not.
>
That would be a typo which didn't show up in my unit test. :)

> There are a lot of functions that do:
>         char *k = estrndup(key, key_len);
> Wouldn't it be more efficient to try to use alloca if it's available?
>
Probably.  I'll change that.

> "c" functions can be a bit dangerous, since they assume the argument is
> a constant supplied directly in the macro, but there's no way to catch
> it if somebody does something like name="foo"; php_array_fetchc(bar, foo);
>
Yeah, it was a micro-optimization I threw in for the hell of it.
Already convinced it doesn't belong.

-Sara