Re: [RFC] Simplified Array API for extensions
| From: | Sara Golemon | Date: | Wed, 03 Apr 2013 16:55:18 +0000 |
| Subject: | Re: [RFC] Simplified Array API for extensions | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-66920@lists.php.net to get a copy of this message | ||
> 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