\o/ thanks
-Hannes
On Fri, May 29, 2015 at 3:54 PM, Sara Golemon poll...@php.net wrote:
Not thoroughly tested, but it compiles at least.
Give the latest commit a shot:
https://github.com/sgolemon/php-array-api/commit/1274a2bcbc3eca78dbd35702136b0034b67afc8f
-Sara
On Fri, May 29, 2015 at
What are the chances anyone updated this to support PHP7 yet?
-Hannes
On Mon, Aug 11, 2014 at 5:17 PM, Andrea Faulds a...@ajf.me wrote:
On 12 Aug 2014, at 01:15, Tjerk Meesters tjerk.meest...@gmail.com wrote:
On 12 Aug, 2014, at 5:03 am, Andrea Faulds a...@ajf.me wrote:
On 11 Aug
Not thoroughly tested, but it compiles at least.
Give the latest commit a shot:
https://github.com/sgolemon/php-array-api/commit/1274a2bcbc3eca78dbd35702136b0034b67afc8f
-Sara
On Fri, May 29, 2015 at 1:25 PM, Sara Golemon poll...@php.net wrote:
Ah, well that I'll probably do soonish, but as you
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
I was hoping someone had ported that header file to PHP7 too, for
easier upgrade path from PHP5 for projects already using it :]
-Hannes
On Fri, May 29, 2015 at 12:33 PM, Sara Golemon poll...@php.net wrote:
Yeah, way too late for PHP 7.0, but on the plus side the zend hash API
has changed in
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
On Fri, May 29, 2015 at 12:14
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.magnus...@gmail.com wrote:
I was hoping someone had ported that header file to PHP7 too, for
easier upgrade path from
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.magnus...@gmail.com wrote:
On Tue, Apr 2, 2013 at 7:52 PM, Sara Golemon poll...@php.net wrote:
https://wiki.php.net/rfc/php-array-api
Time to commit?
-Hannes
--
On 11 Aug 2014, at 22:00, Hannes Magnusson hannes.magnus...@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).
--
Andrea
On Mon, Aug 11, 2014 at 2:03 PM, Andrea Faulds a...@ajf.me wrote:
On 11 Aug 2014, at 22:00, Hannes Magnusson hannes.magnus...@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
On 12 Aug, 2014, at 5:03 am, Andrea Faulds a...@ajf.me wrote:
On 11 Aug 2014, at 22:00, Hannes Magnusson hannes.magnus...@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
On 12 Aug 2014, at 01:15, Tjerk Meesters tjerk.meest...@gmail.com wrote:
On 12 Aug, 2014, at 5:03 am, Andrea Faulds a...@ajf.me wrote:
On 11 Aug 2014, at 22:00, Hannes Magnusson hannes.magnus...@gmail.com
wrote:
I think it would be fantastic if this would be included in 5.6.
Too
On Wed, Apr 3, 2013 at 9:43 PM, Joe Watkins krak...@php.net wrote:
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
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?
On 4/4/13, Nikita Popov nikita@gmail.com wrote:
On Wed, Apr 3, 2013 at 9:43 PM, Joe Watkins
hi Sara,
On Wed, Apr 3, 2013 at 4:52 AM, Sara Golemon poll...@php.net wrote:
https://wiki.php.net/rfc/php-array-api
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
Hi!
https://wiki.php.net/rfc/php-array-api
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
On Wed, Apr 3, 2013 at 4:52 AM, Sara Golemon poll...@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.
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
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
1a) 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
On 04/03/2013 06:23 PM, Sara Golemon wrote:
1a) 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
On 04/03/2013 08:43 PM, Joe Watkins wrote:
On 04/03/2013 06:23 PM, Sara Golemon wrote:
1a) 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
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
On 04/04/2013 04:09 AM, Sara Golemon wrote:
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
https://wiki.php.net/rfc/php-array-api
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 04/02/2013 07:52 PM, Sara Golemon wrote:
https://wiki.php.net/rfc/php-array-api
Very nice. I would love to see more of the API simplified for common
tasks like this. It is a macro jungle currently.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On Tue, Apr 2, 2013 at 9:14 PM, Rasmus Lerdorf wrote:
On 04/02/2013 07:52 PM, Sara Golemon wrote:
https://wiki.php.net/rfc/php-array-api
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
27 matches
Mail list logo
