Very nice. I would love to see more of the API simplified for common
tasks like this. It is a macro jungle currently.
-Rasmus
Very nice. I would love to see more of the API simplified for common
tasks like this. It is a macro jungle currently.-Rasmus
Coming from a mostly user land developer but one that likes to attempt to
navigate the internals this is a massive step forward. One of the hardest
things coming from the outside is attempting to navigate the "macro jungle"
as you call it. lxr certainly helps a massive amount but even sometimes
understanding what those macros are supposed to be can a bit complex.
Navigating a cleaner API such as this I believe will assist in a cleaner
and much more clear implementation downstream. These types of changes to
PHP can assist the PHP ecosystem in terms of contributors and overall
maintenance of the language.
- Mike
hi Sara,
Love it, great work. +1 :)
I would like to kill other APIs in next major as well, time for
cleanup and ease maintenance. Yes, it is a bit more work for
extensions developers but as you plan to do pecl releases as well for
these inlined functions, that should be a good thing in the long run.
What do you think about having the same for hashes? Many
implementations do not work with zval but with hash tables as well,
that would be a perfect combination :)
Cheers,
Pierre
@pierrejoye
I would like to kill other APIs in next major as well, time for
cleanup and ease maintenance. Yes, it is a bit more work for
extensions developers but as you plan to do pecl releases as well for
these inlined functions, that should be a good thing in the long run.
I'm not sure how you plan to kill the other APIs since these wrappers
depend on them. Also, the engine uses them heavily for... everything.
What do you think about having the same for hashes? Many
implementations do not work with zval but with hash tables as well,
that would be a perfect combination :)
One of the implementation details which this API hides is the fact
that zend_hash_find() returns a zval** which is usually just an
annoyance to an extension developer, but can be taken advantage of for
rewriting array contents (lookup a value and replace in via *ppzval =
pzval; )
Not to mention the quick_* variants which CVs and the default class
handlers make heavy use of, but are overkill for the average one-off
access from an ext function.
-Sara
Hi!
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...
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.
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?
"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);
Thanks,
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
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, otherwiseNULLis 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
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:
- 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
- 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
1a) The "c" modifier seems like an unnecessary microoptimization. Compilers
should be able to optimizestrlen()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.
Yeah, killing this for sure.
1b) 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.
Yeah, the safe version wasn't meant to capture a common case, but it
is one I've found myself running into more a little commonly. The
argument that the rest of the runtime doesn't provide this affordance
is a good one, but I'm still on the fence for this one.
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
+1 for consistency, combined with separating out the type conversion
bits the verbosity (which I was trying to avoid) is also not so bad.
- 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
:)
It's outside the scope of what I was originally trying to accomplish,
but it's got utility in its own right. So I'll rewrite this entire
proposal as two separate tasks:
#1 - Array access APIs for fetching zval*
zend_array_(fetch|exists|unset)_(assoc|assocl|index|zval)()
#1a - (Optional) Array add APIs renamed for consistency and namespacing:
I'm not a huge fan of this as we'd need to keep
add_(assoc|(next_)?index)_{$type}(), but it's the sort of moment to
embrace consistency in the hopes of deprecating the old calls when we
hit 6.0
#1b - (Optional) Some kind of foreach structure which specializes
zend_hash_apply for the array case:
void callback(zval *key, zval *val, void optionalArg) {
/ key as a zval owned by the iterator (is_ref=0,rc=2 - force
callee to copy if they want to keep it)
zend_hash_key might be more "to the point", but zval is a much
more familiar structure /
/ user code here, none of that ZEND_HASH_APPLY_KEEP stuff though */
}
zend_array_apply(arr, callback, optionalArg);
#2 Scalar zval* accessors (with implicit type conversions):
zend_(bool|long|double|string)_value()
zend_is_true() technically covers zend_bool_value() already, but for
consistency...
And yes, I think we should move em down to Zend...
-Sara
1a) The "c" modifier seems like an unnecessary microoptimization. Compilers
should be able to optimizestrlen()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.Yeah, killing this for sure.
1b) 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.Yeah, the safe version wasn't meant to capture a common case, but it
is one I've found myself running into more a little commonly. The
argument that the rest of the runtime doesn't provide this affordance
is a good one, but I'm still on the fence for this one.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+1 for consistency, combined with separating out the type conversion
bits the verbosity (which I was trying to avoid) is also not so bad.
- 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
:)It's outside the scope of what I was originally trying to accomplish,
but it's got utility in its own right. So I'll rewrite this entire
proposal as two separate tasks:#1 - Array access APIs for fetching zval*
zend_array_(fetch|exists|unset)_(assoc|assocl|index|zval)()
#1a - (Optional) Array add APIs renamed for consistency and namespacing:
I'm not a huge fan of this as we'd need to keep
add_(assoc|(next_)?index)_{$type}(), but it's the sort of moment to
embrace consistency in the hopes of deprecating the old calls when we
hit 6.0#1b - (Optional) Some kind of foreach structure which specializes
zend_hash_apply for the array case:
void callback(zval *key, zval *val, void optionalArg) {
/ key as a zval owned by the iterator (is_ref=0,rc=2 - force
callee to copy if they want to keep it)
zend_hash_key might be more "to the point", but zval is a much
more familiar structure /
/ user code here, none of that ZEND_HASH_APPLY_KEEP stuff though */
}zend_array_apply(arr, callback, optionalArg);
#2 Scalar zval* accessors (with implicit type conversions):
zend_(bool|long|double|string)_value()
zend_is_true() technically covers zend_bool_value() already, but for
consistency...And yes, I think we should move em down to Zend...
-Sara
Hi Sara,
A logical extension of this idea would be to drop array and cover
objects too, one uniform everything API is very appealing, and way
easier to document properly.
Something alone the lines of:
static inline
zend_bool php_exists(zval *pzval, const char *key) {
switch (Z_TYPE(pzval)) {
case IS_ARRAY:
return zend_symtable_exists(Z_ARRVAL_P(pzval), key,
strlen(key) + 1);
default: {
if (Z_OBJ_HT_P(pzval)->has_property) {
return Z_OBJ_HT_P(pzval)->has_property(
pzval, key, strlen(key) + 1, 2 `NULL` TSRMLS_CC
);
} else {
return zend_symtable_exists(
Z_OBJPROP_P(pzval), key, strlen(key) + 1);
}
}
}
}
Just a thought ..
Joe
1a) The "c" modifier seems like an unnecessary microoptimization.
Compilers
should be able to optimizestrlen()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.Yeah, killing this for sure.
1b) 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.Yeah, the safe version wasn't meant to capture a common case, but it
is one I've found myself running into more a little commonly. The
argument that the rest of the runtime doesn't provide this affordance
is a good one, but I'm still on the fence for this one.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+1 for consistency, combined with separating out the type conversion
bits the verbosity (which I was trying to avoid) is also not so bad.
- 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
:)It's outside the scope of what I was originally trying to accomplish,
but it's got utility in its own right. So I'll rewrite this entire
proposal as two separate tasks:#1 - Array access APIs for fetching zval*
zend_array_(fetch|exists|unset)_(assoc|assocl|index|zval)()
#1a - (Optional) Array add APIs renamed for consistency and namespacing:
I'm not a huge fan of this as we'd need to keep
add_(assoc|(next_)?index)_{$type}(), but it's the sort of moment to
embrace consistency in the hopes of deprecating the old calls when we
hit 6.0#1b - (Optional) Some kind of foreach structure which specializes
zend_hash_apply for the array case:
void callback(zval *key, zval *val, void optionalArg) {
/ key as a zval owned by the iterator (is_ref=0,rc=2 - force
callee to copy if they want to keep it)
zend_hash_key might be more "to the point", but zval is a much
more familiar structure /
/ user code here, none of that ZEND_HASH_APPLY_KEEP stuff though */
}zend_array_apply(arr, callback, optionalArg);
#2 Scalar zval* accessors (with implicit type conversions):
zend_(bool|long|double|string)_value()
zend_is_true() technically covers zend_bool_value() already, but for
consistency...And yes, I think we should move em down to Zend...
-Sara
Hi Sara,
A logical extension of this idea would be to drop array and cover
objects too, one uniform everything API is very appealing, and way
easier to document properly.Something alone the lines of:
static inline
zend_bool php_exists(zval *pzval, const char *key) {
switch (Z_TYPE(pzval)) {
case IS_ARRAY:
return zend_symtable_exists(Z_ARRVAL_P(pzval), key,
strlen(key) + 1);default: { if (Z_OBJ_HT_P(pzval)->has_property) { return Z_OBJ_HT_P(pzval)->has_property( pzval, key, strlen(key) + 1, 2 `NULL` TSRMLS_CC ); } else { return zend_symtable_exists( Z_OBJPROP_P(pzval), key, strlen(key) + 1); } } }}
Just a thought ..
Joe
https://gist.github.com/krakjoe/5304945
I'd be happy to complete/test it if we think it's a worthy direction to
go in ... a unified api does look delicious, it's a bit more complex
than arrays but then in extensions you want/need to deal with objects as
much as, if note more than, you do arrays ...
Joe
A logical extension of this idea would be to drop array and cover
objects too, one uniform everything API is very appealing, and way
easier to document properly.https://gist.github.com/krakjoe/5304945
I'd be happy to complete/test it if we think it's a worthy direction to go
in ... a unified api does look delicious, it's a bit more complex than
arrays but then in extensions you want/need to deal with objects as much as,
if note more than, you do arrays ...
While I'm in favor of an API which covers both Arrays and Object
properties, I don't want to go too far in the direction of generically
named APIs. php_exists() is, I think, too far. I'm not sure what's
the right middle-ground of being both descriptive and concise, but I'm
sure we can sort that out.
A logical extension of this idea would be to drop array and cover
objects too, one uniform everything API is very appealing, and way
easier to document properly.https://gist.github.com/krakjoe/5304945
I'd be happy to complete/test it if we think it's a worthy direction to go
in ... a unified api does look delicious, it's a bit more complex than
arrays but then in extensions you want/need to deal with objects as much as,
if note more than, you do arrays ...While I'm in favor of an API which covers both Arrays and Object
properties, I don't want to go too far in the direction of generically
named APIs. php_exists() is, I think, too far. I'm not sure what's
the right middle-ground of being both descriptive and concise, but I'm
sure we can sort that out.
Morning,
Yeah maybe a bit far, php_exists doesn't really have any context ...
I'm all in favour of php_object_exists php_array_exists both having the
exact same prototypes and sharing documentation, it just seems a waste
to write object/array at all ...
Any other ideas, or just go with object/array ?
Joe
Hi Sara,
A logical extension of this idea would be to drop array and cover
objects too, one uniform everything API is very appealing, and way easier
to document properly.Something alone the lines of:
static inline
zend_bool php_exists(zval *pzval, const char *key) {
switch (Z_TYPE(pzval)) {
case IS_ARRAY:
return zend_symtable_exists(Z_ARRVAL_**P(pzval), key,
strlen(key) + 1);default: { if (Z_OBJ_HT_P(pzval)->has_**property) { return Z_OBJ_HT_P(pzval)->has_**property( pzval, key, strlen(key) + 1, 2 `NULL` TSRMLS_CC ); } else { return zend_symtable_exists( Z_OBJPROP_P(pzval), key, strlen(key) + 1); } } }}
Just a thought ..
Strong -1 on anything that tries to treat objects as if they were arrays of
properties. I think much damage has already been done by using object
properties as an array in some places and we should not go further down
that road. I have no problem with nice APIs for object properties access,
but please, please do not mix both.
Nikita
The idea was to avoid treating the object as an array of properties
where there is another option. Where there isn't an option the objects
properties have to be accessed as an array dont they?
Hi Sara,
A logical extension of this idea would be to drop array and cover
objects too, one uniform everything API is very appealing, and way easier
to document properly.Something alone the lines of:
static inline
zend_bool php_exists(zval *pzval, const char *key) {
switch (Z_TYPE(pzval)) {
case IS_ARRAY:
return zend_symtable_exists(Z_ARRVAL_**P(pzval), key,
strlen(key) + 1);default: { if (Z_OBJ_HT_P(pzval)->has_**property) { return Z_OBJ_HT_P(pzval)->has_**property( pzval, key, strlen(key) + 1, 2 `NULL` TSRMLS_CC ); } else { return zend_symtable_exists( Z_OBJPROP_P(pzval), key, strlen(key) + 1); } } }}
Just a thought ..
Strong -1 on anything that tries to treat objects as if they were arrays of
properties. I think much damage has already been done by using object
properties as an array in some places and we should not go further down
that road. I have no problem with nice APIs for object properties access,
but please, please do not mix both.Nikita
I think it would be fantastic if this would be included in 5.6.
-Hannes
On Wed, Nov 6, 2013 at 2:14 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
Time to commit?
-Hannes
I think it would be fantastic if this would be included in 5.6.
Too late for 5.6, but 5.7 perhaps (can we please have this? 7 will break BC and I’d like to get some stuff in next year, not in 2 years).
--
Andrea Faulds
http://ajf.me/
I think it would be fantastic if this would be included in 5.6.
Too late for 5.6, but 5.7 perhaps (can we please have this? 7 will break BC and I’d like to get some stuff in next year, not in 2 years).
Yeah, I keep dropping this because... SQUIRREL!!!!!!
Anyone fancy taking it over from me? The original version is still
sitting at https://github.com/sgolemon/php-array-api
-Sara
I think it would be fantastic if this would be included in 5.6.
Too late for 5.6, but 5.7 perhaps (can we please have this? 7 will break BC and I’d like to get some stuff in next year, not in 2 years).
Can this API be retained as is when NG gets merged?
I would hate to see developers put in effort to take advantage of this simplified API in 5.x only to have to make changes again for 7.
--
Andrea Faulds
http://ajf.me/
I think it would be fantastic if this would be included in 5.6.
Too late for 5.6, but 5.7 perhaps (can we please have this? 7 will break BC and I’d like to get some stuff in next year, not in 2 years).
Can this API be retained as is when NG gets merged?
I would hate to see developers put in effort to take advantage of this simplified API in 5.x only to have to make changes again for 7.
If it can’t, I’d suggest only adding this in ng in the first place.
Andrea Faulds
http://ajf.me/
What are the chances anyone updated this to support PHP7 yet?
-Hannes
I think it would be fantastic if this would be included in 5.6.
Too late for 5.6, but 5.7 perhaps (can we please have this? 7 will break BC and I’d like to get some stuff in next year, not in 2 years).
Can this API be retained as is when NG gets merged?
I would hate to see developers put in effort to take advantage of this simplified API in 5.x only to have to make changes again for 7.
If it can’t, I’d suggest only adding this in ng in the first place.
Andrea Faulds
http://ajf.me/
Naive answer: P(inclusion) = 0, due to the feature freeze. Unless I'm
mistaken.
If so, you might need to target 7.1 instead of 7.0.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com
On Fri, May 29, 2015 at 2:56 PM, Hannes Magnusson <
hannes.magnusson@gmail.com> wrote:
What are the chances anyone updated this to support PHP7 yet?
-Hannes
On 12 Aug 2014, at 01:15, Tjerk Meesters tjerk.meesters@gmail.com
wrote:On 11 Aug 2014, at 22:00, Hannes Magnusson hannes.magnusson@gmail.com
wrote:I think it would be fantastic if this would be included in 5.6.
Too late for 5.6, but 5.7 perhaps (can we please have this? 7 will
break BC and I’d like to get some stuff in next year, not in 2 years).Can this API be retained as is when NG gets merged?
I would hate to see developers put in effort to take advantage of this
simplified API in 5.x only to have to make changes again for 7.If it can’t, I’d suggest only adding this in ng in the first place.
Andrea Faulds
http://ajf.me/
Yeah, way too late for PHP 7.0, but on the plus side the zend hash API
has changed in ways which make this facade much less necessary. Not
redundant, necessarily, but the biggest pain point (getting zval** by
reference) is gone (we now get zval* via return).
-Sara
Naive answer: P(inclusion) = 0, due to the feature freeze. Unless I'm
mistaken.If so, you might need to target 7.1 instead of 7.0.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.comOn Fri, May 29, 2015 at 2:56 PM, Hannes Magnusson <
hannes.magnusson@gmail.com> wrote:What are the chances anyone updated this to support PHP7 yet?
-Hannes
On 12 Aug 2014, at 01:15, Tjerk Meesters tjerk.meesters@gmail.com
wrote:On 11 Aug 2014, at 22:00, Hannes Magnusson hannes.magnusson@gmail.com
wrote:I think it would be fantastic if this would be included in 5.6.
Too late for 5.6, but 5.7 perhaps (can we please have this? 7 will
break BC and I’d like to get some stuff in next year, not in 2 years).Can this API be retained as is when NG gets merged?
I would hate to see developers put in effort to take advantage of this
simplified API in 5.x only to have to make changes again for 7.If it can’t, I’d suggest only adding this in ng in the first place.
Andrea Faulds
http://ajf.me/
I was hoping someone had ported that header file to PHP7 too, for
easier upgrade path from PHP5 for projects already using it :]
-Hannes
Yeah, way too late for PHP 7.0, but on the plus side the zend hash API
has changed in ways which make this facade much less necessary. Not
redundant, necessarily, but the biggest pain point (getting zval** by
reference) is gone (we now get zval* via return).-Sara
Naive answer: P(inclusion) = 0, due to the feature freeze. Unless I'm
mistaken.If so, you might need to target 7.1 instead of 7.0.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.comOn Fri, May 29, 2015 at 2:56 PM, Hannes Magnusson <
hannes.magnusson@gmail.com> wrote:What are the chances anyone updated this to support PHP7 yet?
-Hannes
On 12 Aug 2014, at 01:15, Tjerk Meesters tjerk.meesters@gmail.com
wrote:On 11 Aug 2014, at 22:00, Hannes Magnusson hannes.magnusson@gmail.com
wrote:I think it would be fantastic if this would be included in 5.6.
Too late for 5.6, but 5.7 perhaps (can we please have this? 7 will
break BC and I’d like to get some stuff in next year, not in 2 years).Can this API be retained as is when NG gets merged?
I would hate to see developers put in effort to take advantage of this
simplified API in 5.x only to have to make changes again for 7.If it can’t, I’d suggest only adding this in ng in the first place.
Andrea Faulds
http://ajf.me/
Ah, well that I'll probably do soonish, but as you already know, it
doesn't need to be in the php-src tree to work. :)
On Fri, May 29, 2015 at 12:37 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
I was hoping someone had ported that header file to PHP7 too, for
easier upgrade path from PHP5 for projects already using it :]-Hannes
Yeah, way too late for PHP 7.0, but on the plus side the zend hash API
has changed in ways which make this facade much less necessary. Not
redundant, necessarily, but the biggest pain point (getting zval** by
reference) is gone (we now get zval* via return).-Sara
Naive answer: P(inclusion) = 0, due to the feature freeze. Unless I'm
mistaken.If so, you might need to target 7.1 instead of 7.0.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.comOn Fri, May 29, 2015 at 2:56 PM, Hannes Magnusson <
hannes.magnusson@gmail.com> wrote:What are the chances anyone updated this to support PHP7 yet?
-Hannes
On 12 Aug 2014, at 01:15, Tjerk Meesters tjerk.meesters@gmail.com
wrote:On 11 Aug 2014, at 22:00, Hannes Magnusson hannes.magnusson@gmail.com
wrote:I think it would be fantastic if this would be included in 5.6.
Too late for 5.6, but 5.7 perhaps (can we please have this? 7 will
break BC and I’d like to get some stuff in next year, not in 2 years).Can this API be retained as is when NG gets merged?
I would hate to see developers put in effort to take advantage of this
simplified API in 5.x only to have to make changes again for 7.If it can’t, I’d suggest only adding this in ng in the first place.
Andrea Faulds
http://ajf.me/
Not thoroughly tested, but it compiles at least.
Give the latest commit a shot:
https://github.com/sgolemon/php-array-api/commit/1274a2bcbc3eca78dbd35702136b0034b67afc8f
-Sara
Ah, well that I'll probably do soonish, but as you already know, it
doesn't need to be in the php-src tree to work. :)On Fri, May 29, 2015 at 12:37 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:I was hoping someone had ported that header file to PHP7 too, for
easier upgrade path from PHP5 for projects already using it :]-Hannes
Yeah, way too late for PHP 7.0, but on the plus side the zend hash API
has changed in ways which make this facade much less necessary. Not
redundant, necessarily, but the biggest pain point (getting zval** by
reference) is gone (we now get zval* via return).-Sara
Naive answer: P(inclusion) = 0, due to the feature freeze. Unless I'm
mistaken.If so, you might need to target 7.1 instead of 7.0.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.comOn Fri, May 29, 2015 at 2:56 PM, Hannes Magnusson <
hannes.magnusson@gmail.com> wrote:What are the chances anyone updated this to support PHP7 yet?
-Hannes
On 12 Aug 2014, at 01:15, Tjerk Meesters tjerk.meesters@gmail.com
wrote:On 11 Aug 2014, at 22:00, Hannes Magnusson hannes.magnusson@gmail.com
wrote:I think it would be fantastic if this would be included in 5.6.
Too late for 5.6, but 5.7 perhaps (can we please have this? 7 will
break BC and I’d like to get some stuff in next year, not in 2 years).Can this API be retained as is when NG gets merged?
I would hate to see developers put in effort to take advantage of this
simplified API in 5.x only to have to make changes again for 7.If it can’t, I’d suggest only adding this in ng in the first place.
Andrea Faulds
http://ajf.me/
\o/ thanks
-Hannes
Not thoroughly tested, but it compiles at least.
Give the latest commit a shot:
https://github.com/sgolemon/php-array-api/commit/1274a2bcbc3eca78dbd35702136b0034b67afc8f-Sara
Ah, well that I'll probably do soonish, but as you already know, it
doesn't need to be in the php-src tree to work. :)On Fri, May 29, 2015 at 12:37 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:I was hoping someone had ported that header file to PHP7 too, for
easier upgrade path from PHP5 for projects already using it :]-Hannes
Yeah, way too late for PHP 7.0, but on the plus side the zend hash API
has changed in ways which make this facade much less necessary. Not
redundant, necessarily, but the biggest pain point (getting zval** by
reference) is gone (we now get zval* via return).-Sara
Naive answer: P(inclusion) = 0, due to the feature freeze. Unless I'm
mistaken.If so, you might need to target 7.1 instead of 7.0.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.comOn Fri, May 29, 2015 at 2:56 PM, Hannes Magnusson <
hannes.magnusson@gmail.com> wrote:What are the chances anyone updated this to support PHP7 yet?
-Hannes
On 12 Aug 2014, at 01:15, Tjerk Meesters tjerk.meesters@gmail.com
wrote:On 11 Aug 2014, at 22:00, Hannes Magnusson hannes.magnusson@gmail.com
wrote:I think it would be fantastic if this would be included in 5.6.
Too late for 5.6, but 5.7 perhaps (can we please have this? 7 will
break BC and I’d like to get some stuff in next year, not in 2 years).Can this API be retained as is when NG gets merged?
I would hate to see developers put in effort to take advantage of this
simplified API in 5.x only to have to make changes again for 7.If it can’t, I’d suggest only adding this in ng in the first place.
Andrea Faulds
http://ajf.me/