Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
发自我的 iPhone 在 2013-4-3，13:56，Hannes Magnusson hannes.magnus...@gmail.com 写道： Wait wait wait. You are introducing a constant that is going to be available as of 5.4.15 to 5.4.2x and then removed (as it looks like we are agreeing)? how could that be? This constant will in the final release of 5.5.0. Thanks People have been living without this constant forever now so people have their workarounds in place and no need to complicate their code to for the existence of this constant which is only available for few bugfix releases anyway? -Hannes On Tue, Apr 2, 2013 at 7:19 PM, Laruence larue...@php.net wrote: Added new constant CURL_WRAPPERS_ENABLE in (include 5.4) https://github.com/php/php-src/commit/d7f709a032a40cb475042b43db07a4698a2488b7 thanks On Mon, Apr 1, 2013 at 9:53 PM, Laruence larue...@php.net wrote: On Mon, Apr 1, 2013 at 7:18 AM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Sun, Mar 31, 2013 at 6:25 AM, Laruence larue...@php.net wrote: Hey: there are some issues when people run some codes in a php which is compiled with --with-curlwrappers, like #61336, or the recently test script for #64433 (failed when curl wrappers enabled). I know, that the curl wrapper should act the same as php http wrapper, but for now, we need to provide the ability to user, that they can warn if they codes can not run with curl wrappers.. here are some really usages: https://github.com/UnionOfRAD/lithium/issues/59 and http://weizhifeng.net/wrong-with-curlwrappers.html I propose to add a constant : bool CURL_WRAPPERS_ENABLE The curl wrappers have always been a major pain, with plenty of bugs and we tend to forget to add context options there to match the standard wrapper on new feature. It has been marked as experimental since forever, and I think its time to face the failed experiment and remove it. Hey: remove is also okey for me, but, I think it probably can only happen in 5.6 before that, I think a flag to 5.4+ is a good choice :) thanks -Hannes -- Laruence Xinchen Hui http://www.laruence.com/ -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
On Wed, Apr 3, 2013 at 8:10 AM, Xinchen Hui larue...@gmail.com wrote: 发自我的 iPhone 在 2013-4-3，13:56，Hannes Magnusson hannes.magnus...@gmail.com 写道： Wait wait wait. You are introducing a constant that is going to be available as of 5.4.15 to 5.4.2x and then removed (as it looks like we are agreeing)? how could that be? This constant will in the final release of 5.5.0. Thanks What Hannes wanted to say that we seem to agree that this experimental feature was a failure and it should be removed. If we only remove this in 5.6 then I agree that adding the constant is worthwhile, but if we would remove it with 5.5.0, then I'm not that sure, as people already has their workarounds. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] Simplified Array API for extensions
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 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
Hi Laruence
2013/3/31 Laruence larue...@php.net
I propose to add a constant : bool CURL_WRAPPERS_ENABLE
or, any other better name...
objections?
I'm a -1 on this, because as we sort of agreed on (like Hannes
implied), this experimental feature did not turn out as we wanted, its
buggy and nobody maintains it. Currently to figure out if PHP was
built with curlwrappers, theres this dirty hack by printing the
phpinfo() page into an output buffer, to parse it for the build
string, this sucks.
However, since this is an experimental feature, we should either:
1) Make it work (most unlikely)
2) Remove it
Instead of adding tiny hacks to make it easier (I know a constant wont
hurt much). Cross version code is also gonna end up with even more
clutter, imagine this (if you want to utilize this new constant, which
is the idea right?):
$curlwrappers = false;
if(defined('CURL_WRAPPERS_ENABLED')) {
$curlwrappers = true;
} else {
ob_start();
phpinfo(INFO_GENERAL);
if(strpos('with-curlwrappers', ob_get_clean()) !== false) {
$curlwrappers = true;
}
}
What I'm saying is (like Hannes), adding a constant thats only gonna
be available for one minor version, is not worth it, we lived years
without it and we can live a little longer until it finally dies.
Also, seeing you already added the constant, it should be named
CURL_WRAPPERS_ENABLED, not ENABLE because it implies that its an
option used in a write context, where this constant is purely meant to
be used in a read context.
--
regards,
Kalle Sommer Nielsen
ka...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
On Wed, Apr 3, 2013 at 12:31 AM, Kalle Sommer Nielsen ka...@php.net wrote:
Hi Laruence
2013/3/31 Laruence larue...@php.net
I propose to add a constant : bool CURL_WRAPPERS_ENABLE
or, any other better name...
objections?
I'm a -1 on this, because as we sort of agreed on (like Hannes
implied), this experimental feature did not turn out as we wanted, its
buggy and nobody maintains it. Currently to figure out if PHP was
built with curlwrappers, theres this dirty hack by printing the
phpinfo() page into an output buffer, to parse it for the build
string, this sucks.
However, since this is an experimental feature, we should either:
1) Make it work (most unlikely)
2) Remove it
Instead of adding tiny hacks to make it easier (I know a constant wont
hurt much). Cross version code is also gonna end up with even more
clutter, imagine this (if you want to utilize this new constant, which
is the idea right?):
$curlwrappers = false;
if(defined('CURL_WRAPPERS_ENABLED')) {
$curlwrappers = true;
You'll actually have to assign the value of CURL_WRAPPERS_ENABLED to
$curlwrappers, as defined() only checks if the constant exist.. not if
its set to true :)
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
2013/4/3 Hannes Magnusson hannes.magnus...@gmail.com:
You'll actually have to assign the value of CURL_WRAPPERS_ENABLED to
$curlwrappers, as defined() only checks if the constant exist.. not if
its set to true :)
well, s/defined('CURL_WRAPPERS_ENABLED')/defined('CURL_WRAPPERS_ENABLED')
CURL_WRAPPERS_ENABLED/
Doesn't make it prettier (either way) =)
--
regards,
Kalle Sommer Nielsen
ka...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Simplified Array API for extensions
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 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
Hi! Added new constant CURL_WRAPPERS_ENABLE in (include 5.4) https://github.com/php/php-src/commit/d7f709a032a40cb475042b43db07a4698a2488b7 I must say the process of how it was done was not very good. Not only there were no substantial discussion on adding this new thing in stable version before the commit, the time between message announcing it and asking if there are any objections and the commit was barely a day. It's not enough time at all to solicit feedback, and this change is not really something urgent that needs to be committed ASAP. And it turns out, there *are* objections. Could we be a little less quick with commits into a stable version and give it some time when we're talking about new things and not bugfixes? Thanks, -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
On Wed, Apr 3, 2013 at 4:22 PM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! Added new constant CURL_WRAPPERS_ENABLE in (include 5.4) https://github.com/php/php-src/commit/d7f709a032a40cb475042b43db07a4698a2488b7 I must say the process of how it was done was not very good. Not only there were no substantial discussion on adding this new thing in stable version before the commit, the time between message announcing it and asking if there are any objections and the commit was barely a day. It's not enough time at all to solicit feedback, and this change is not really something urgent that needs to be committed ASAP. And it turns out, there *are* objections. Could we be a little less quick with commits into a stable version and give it some time when we're talking about new things and not bugfixes? Hey: I have to say, the objections only shows up after it happens.. but yes, I am a little rush at this commit, that is because, you can see, the test script in ext/standard/tests/stream is depends on a ugly trick to skip . it make me very uncomfortable. I send the mail the day before yesterday, and it's really not a big change (add a constant), then no new feedback in a day, I think it's okey to commit. however, you are right, it's not a long time, so if objections becomes strong, I can revert it. thanks Thanks, -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- Laruence Xinchen Hui http://www.laruence.com/
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
On Wed, Apr 3, 2013 at 10:22 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Added new constant CURL_WRAPPERS_ENABLE in (include 5.4) https://github.com/php/php-src/commit/d7f709a032a40cb475042b43db07a4698a2488b7 I must say the process of how it was done was not very good. Not only there were no substantial discussion on adding this new thing in stable version before the commit, the time between message announcing it and asking if there are any objections and the commit was barely a day. It's not enough time at all to solicit feedback, and this change is not really something urgent that needs to be committed ASAP. And it turns out, there *are* objections. Could we be a little less quick with commits into a stable version and give it some time when we're talking about new things and not bugfixes? I'd to agree. I was surprised to see a commit this morning. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Improve Warning when loading Zend Ext as PHP module
Hi, with opcache being bundled I expectr to see multiple bugs like #64568 where users are trying to load opcache as PHP module (using extension= in php.ini), I tried to improve the error message a bit. In https://github.com/johannes/php-src/commit/a1301253a44de3997548cbd8f83e38d79e4c331c the PHP module loader will, in case of an error, check for Zend Extension symbols and give a more verbose error . Any opinions on this? johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improve Warning when loading Zend Ext as PHP module
Wed, Apr 3, 2013 at 11:01 AM, Johannes Schlüter johan...@schlueters.dewrote: Hi, with opcache being bundled I expectr to see multiple bugs like #64568 where users are trying to load opcache as PHP module (using extension= in php.ini), I tried to improve the error message a bit. In https://github.com/johannes/php-src/commit/a1301253a44de3997548cbd8f83e38d79e4c331c the PHP module loader will, in case of an error, check for Zend Extension symbols and give a more verbose error . Any opinions on this? +1, I like it Julien.Pauli
Re: [PHP-DEV] Improve Warning when loading Zend Ext as PHP module
Looking good. +1. On Apr 3, 2013 12:23 PM, Julien Pauli jpa...@php.net wrote: Wed, Apr 3, 2013 at 11:01 AM, Johannes Schlüter johan...@schlueters.de wrote: Hi, with opcache being bundled I expectr to see multiple bugs like #64568 where users are trying to load opcache as PHP module (using extension= in php.ini), I tried to improve the error message a bit. In https://github.com/johannes/php-src/commit/a1301253a44de3997548cbd8f83e38d79e4c331c the PHP module loader will, in case of an error, check for Zend Extension symbols and give a more verbose error . Any opinions on this? +1, I like it Julien.Pauli
Re: [PHP-DEV] Improve Warning when loading Zend Ext as PHP module
Wed, Apr 3, 2013 at 11:01 AM, Johannes Schlüter johan...@schlueters.de wrote: Hi, with opcache being bundled I expectr to see multiple bugs like #64568 where users are trying to load opcache as PHP module (using extension= in php.ini), I tried to improve the error message a bit. In https://github.com/johannes/php-src/commit/a1301253a44de3997548cbd8f83e38d79e4c331c the PHP module loader will, in case of an error, check for Zend Extension symbols and give a more verbose error . Any opinions on this? Very good idea, +1 Greetings, Florian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
On Wed, Apr 3, 2013 at 10:37 AM, Laruence larue...@php.net wrote: On Wed, Apr 3, 2013 at 4:22 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Added new constant CURL_WRAPPERS_ENABLE in (include 5.4) https://github.com/php/php-src/commit/d7f709a032a40cb475042b43db07a4698a2488b7 I must say the process of how it was done was not very good. Not only there were no substantial discussion on adding this new thing in stable version before the commit, the time between message announcing it and asking if there are any objections and the commit was barely a day. It's not enough time at all to solicit feedback, and this change is not really something urgent that needs to be committed ASAP. And it turns out, there *are* objections. Could we be a little less quick with commits into a stable version and give it some time when we're talking about new things and not bugfixes? Hey: I have to say, the objections only shows up after it happens this happens more frequently if you don't give a chance to the people to explain their problems before pushing the proposed changes. this weekend and the monday was a national holiday for many countries(Easter) so that was really bad timing. but yes, I am a little rush at this commit, that is because, you can see, the test script in ext/standard/tests/stream is depends on a ugly trick to skip . it make me very uncomfortable. yeah, and that is what everybody else out there has to live with, so nothing really changed apart the fact that you also bumped to the issue. I'm not saying that the situation is ideal, but pushing changes to stable (5.4) or feature frozen (5.5) branches without using the RFC system and waiting for the feedback from the RMs is a bad thing to do. We also have a couple of tests with even more uglier checks (see http://git.php.net/?p=php-src.git;a=blob_plain;f=Zend/tests/bug55509.phpt;hb=HEAD for example), so I don't find that reason that convincing to throw our processes out of the window. I send the mail the day before yesterday, and it's really not a big change (add a constant), then no new feedback in a day, I think it's okey to commit. there were feedback from multiple people that it would be better to remove the whole thing. which you replied that it would be ok with you, then pushed your change. however, you are right, it's not a long time, so if objections becomes strong, I can revert it. this is exactly the kind of behavior why we changed from the commit first then revert when people complaining to the current approach, where we try to reach a concensus (via discussion on the mailing list or voting through RFCs) before introducing a change. the difference between the old and the current approach is that it switches the burden of proof: instead of forcing others to prove that one's already commited change is bad and should be reverted, the author has the burden that his/her change is good enough to get in. another recent example of the problem with the old approach was the discussion about DateTimeImmutable: the majority agreed that it was a bad decision to ship that as-is, but nobody dared to revert it. hopefully Derick defused that situation, props for that. ps: if we end up keeping the constant, please rename it to CURL_WRAPPERS_ENABLED, Kalle summed up pretty well the reasons. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
发自我的 iPhone 在 2013-4-3，20:42，Ferenc Kovacs tyr...@gmail.com 写道： On Wed, Apr 3, 2013 at 10:37 AM, Laruence larue...@php.net wrote: On Wed, Apr 3, 2013 at 4:22 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Added new constant CURL_WRAPPERS_ENABLE in (include 5.4) https://github.com/php/php-src/commit/d7f709a032a40cb475042b43db07a4698a2488b7 I must say the process of how it was done was not very good. Not only there were no substantial discussion on adding this new thing in stable version before the commit, the time between message announcing it and asking if there are any objections and the commit was barely a day. It's not enough time at all to solicit feedback, and this change is not really something urgent that needs to be committed ASAP. And it turns out, there *are* objections. Could we be a little less quick with commits into a stable version and give it some time when we're talking about new things and not bugfixes? Hey: I have to say, the objections only shows up after it happens this happens more frequently if you don't give a chance to the people to explain their problems before pushing the proposed changes. this weekend and the monday was a national holiday for many countries(Easter) so that was really bad timing. but yes, I am a little rush at this commit, that is because, you can see, the test script in ext/standard/tests/stream is depends on a ugly trick to skip . it make me very uncomfortable. yeah, and that is what everybody else out there has to live with, so nothing really changed apart the fact that you also bumped to the issue. I'm not saying that the situation is ideal, but pushing changes to stable (5.4) or feature frozen (5.5) branches without using the RFC system and waiting for the feedback from the RMs is a bad thing to do. We also have a couple of tests with even more uglier checks (see http://git.php.net/?p=php-src.git;a=blob_plain;f=Zend/tests/bug55509.phpt;hb=HEAD for example), so I don't find that reason that convincing to throw our processes out of the window. I send the mail the day before yesterday, and it's really not a big change (add a constant), then no new feedback in a day, I think it's okey to commit. there were feedback from multiple people that it would be better to remove the whole thing. which you replied that it would be ok with you, then pushed your change. however, you are right, it's not a long time, so if objections becomes strong, I can revert it. this is exactly the kind of behavior why we changed from the commit first then revert when people complaining to the current approach, where we try to reach a concensus (via discussion on the mailing list or voting through RFCs) before introducing a change. the difference between the old and the current approach is that it switches the burden of proof: instead of forcing others to prove that one's already commited change is bad and should be reverted, the author has the burden that his/her change is good enough to get in. another recent example of the problem with the old approach was the discussion about DateTimeImmutable: the majority agreed that it was a bad decision to ship that as-is, but nobody dared to revert it. hopefully Derick defused that situation, props for that. are we talking about add a constant only? I always very respect the dev process flow, In this case, one of important reason is : I proposed add a constant , a tiny change, and IMO doenst worth of a RFC. Thanks ps: if we end up keeping the constant, please rename it to CURL_WRAPPERS_ENABLED, Kalle summed up pretty well the reasons. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] Simplified Array API for extensions
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. 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
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
2013/4/3 Laruence larue...@php.net: On Wed, Apr 3, 2013 at 4:22 PM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! Added new constant CURL_WRAPPERS_ENABLE in (include 5.4) https://github.com/php/php-src/commit/d7f709a032a40cb475042b43db07a4698a2488b7 I must say the process of how it was done was not very good. Not only there were no substantial discussion on adding this new thing in stable version before the commit, the time between message announcing it and asking if there are any objections and the commit was barely a day. It's not enough time at all to solicit feedback, and this change is not really something urgent that needs to be committed ASAP. And it turns out, there *are* objections. Could we be a little less quick with commits into a stable version and give it some time when we're talking about new things and not bugfixes? Hey: I have to say, the objections only shows up after it happens.. but yes, I am a little rush at this commit, that is because, you can see, the test script in ext/standard/tests/stream is depends on a ugly trick to skip . it make me very uncomfortable. I send the mail the day before yesterday, and it's really not a big change (add a constant), then no new feedback in a day, I think it's okey to commit. however, you are right, it's not a long time, so if objections becomes strong, I can revert it. I think my argument against adding the constant is at least just as strong as adding it. I agree we shouldn't go RFC/vote etc, over one single constant but I think we can all agree on the fact that we shouldn't try to add hacks to fix usage of an experimental feature (which is essentially what this constant is). We need more consistency, than inconsistencies. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
On Wed, Apr 3, 2013 at 10:42 PM, Kalle Sommer Nielsen ka...@php.net wrote: 2013/4/3 Laruence larue...@php.net: On Wed, Apr 3, 2013 at 4:22 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Added new constant CURL_WRAPPERS_ENABLE in (include 5.4) https://github.com/php/php-src/commit/d7f709a032a40cb475042b43db07a4698a2488b7 I must say the process of how it was done was not very good. Not only there were no substantial discussion on adding this new thing in stable version before the commit, the time between message announcing it and asking if there are any objections and the commit was barely a day. It's not enough time at all to solicit feedback, and this change is not really something urgent that needs to be committed ASAP. And it turns out, there *are* objections. Could we be a little less quick with commits into a stable version and give it some time when we're talking about new things and not bugfixes? Hey: I have to say, the objections only shows up after it happens.. but yes, I am a little rush at this commit, that is because, you can see, the test script in ext/standard/tests/stream is depends on a ugly trick to skip . it make me very uncomfortable. I send the mail the day before yesterday, and it's really not a big change (add a constant), then no new feedback in a day, I think it's okey to commit. however, you are right, it's not a long time, so if objections becomes strong, I can revert it. I think my argument against adding the constant is at least just as strong as adding it. I agree we shouldn't go RFC/vote etc, over one single constant but I think we can all agree on the fact that we shouldn't try to add hacks to fix usage of an experimental feature (which is essentially what this constant is). Hey: but as you see, many people was entrapped by the experimental feature, and whether the experimental is there is out of their hands. I, from a user aspect, I need to know whether my project can run in the host environment. if not, I can warn the user to re-configure it. this is very important. now, the hack way , as you can see, to check if the --with-curlwrappers exists in phpinfo(), doesn't work very well, if the curl extension is built as shared and separated. I don't think adding this flag is a hack way, it's just to reflect some features, like if (class_exists(PDO)), or like (if PHP_VERSION == 5.4)... thanks We need more consistency, than inconsistencies. -- regards, Kalle Sommer Nielsen ka...@php.net -- Laruence Xinchen Hui http://www.laruence.com/
Re: [PHP-DEV] Improve Warning when loading Zend Ext as PHP module
2013/4/3 Johannes Schlüter johan...@schlueters.de: Hi, with opcache being bundled I expectr to see multiple bugs like #64568 where users are trying to load opcache as PHP module (using extension= in php.ini), I tried to improve the error message a bit. In https://github.com/johannes/php-src/commit/a1301253a44de3997548cbd8f83e38d79e4c331c the PHP module loader will, in case of an error, check for Zend Extension symbols and give a more verbose error . Any opinions on this? Sounds good, +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Simplified Array API for extensions
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Simplified Array API for extensions
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Simplified Array API for extensions
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 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.
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
:)
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improve Warning when loading Zend Ext as PHP module
Hi! https://github.com/johannes/php-src/commit/a1301253a44de3997548cbd8f83e38d79e4c331c the PHP module loader will, in case of an error, check for Zend Extension symbols and give a more verbose error . Sounds like a good idea. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
Hi 2013/4/3 Laruence larue...@php.net: Hey: but as you see, many people was entrapped by the experimental feature, and whether the experimental is there is out of their hands. I, from a user aspect, I need to know whether my project can run in the host environment. if not, I can warn the user to re-configure it. this is very important. now, the hack way , as you can see, to check if the --with-curlwrappers exists in phpinfo(), doesn't work very well, if the curl extension is built as shared and separated. I don't think adding this flag is a hack way, it's just to reflect some features, like if (class_exists(PDO)), or like (if PHP_VERSION == 5.4)... I see your point, but I think if we start adding features to an experimental feature is a bad idea, it becomes a concern when people start to rely on experimental features. I don't think it will be a huge concern for the RMs (cc'd) of 5.5 to consider removing curlwrappers, then we are done with that once and for all and we don't even need to add the constant as it would be odd that just a few versions of 5.4.x would have it. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improve Warning when loading Zend Ext as PHP module
Hi 2013/4/3 Johannes Schlüter johan...@schlueters.de: Any opinions on this? Lets just get it committed, +1 -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Simplified Array API for extensions
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 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.
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
:)
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Simplified Array API for extensions
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 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.
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
:)
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
On Wed, Apr 3, 2013 at 5:42 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Wed, Apr 3, 2013 at 10:37 AM, Laruence larue...@php.net wrote: however, you are right, it's not a long time, so if objections becomes strong, I can revert it. this is exactly the kind of behavior why we changed from the commit first then revert when people complaining to the current approach, where we try to reach a concensus (via discussion on the mailing list or voting through RFCs) before introducing a change. I've gotta say, even though I disagree with the commit, writing an RFC for a new constant is a total WTF. There is absolutely no need for a RFC for it. Heck, even that initial curtesy mail was more then I would have expected. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
Hi! There is absolutely no need for a RFC for it. Heck, even that initial curtesy mail was more then I would have expected. Agree, no need for full scale RFC for one constant. However, sending an email to the list and actually waiting for feedback is exactly what I would expect, especially dealing with stable version and feature that it is not exactly clear what's going on with it. We're not talking about writing RFCs for every minor change, we're talking about teamwork and have members of the team be aware of the change and have time to discuss it if needed. Nothing bad would happen if the same commit would land a week later, after everybody is behind it and every detail is hashed out (or not if turns out it is out of consensus). The point here is not to impede work but to support teamwork. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] how to determine errno on user space?
On Tue, 02 Apr 2013 02:11:24 +0200, chobie chobi...@gmail.com wrote: Hi, I'm writing some socket client (fluentd client) with PHP and I have a question. I want to retry fwrite or some socket function when I met recoverable errno (e.g, EAGAIN). but PHP does not have any function to determine errno as far as I known. what is the correct way to handle errno? I'd like to write robust client with PHP but I don't have good idea to determine errno. The sockets extension has socket_last_error() to get the errno value after the last operation on the passed in socket. The stream functions don't really handle this in a consistent fashion. For instance, stream_socket_client() can take a parameter by reference where to write the errno value, but other functions do not give such information and can only inform the user about the specific error that occurred via the a warning, which is not very friendly for programatically extracting the cause. I'd recommend that you use the sockets extension, unless you need encryption. As to your approach, I don't really like it. PHP does not have enumerations, and the approach of creating a very large number of classes for this purpose is unprecedented in the PHP codebase. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
On Wed, Apr 3, 2013 at 2:00 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! There is absolutely no need for a RFC for it. Heck, even that initial curtesy mail was more then I would have expected. Agree, no need for full scale RFC for one constant. However, sending an email to the list and actually waiting for feedback is exactly what I would expect, especially dealing with stable version and feature that it is not exactly clear what's going on with it. We're not talking about writing RFCs for every minor change, we're talking about teamwork and have members of the team be aware of the change and have time to discuss it if needed. Nothing bad would happen if the same commit would land a week later, after everybody is behind it and every detail is hashed out (or not if turns out it is out of consensus). The point here is not to impede work but to support teamwork. There is a thin line between impeding work and team work for such a trivial change. This constant is actually really useful. The entire feature is however unfortunately broken, but had it been in a working shape then common. Really? Send an email and wait a week before being able to write a testcase? Anyway. Lets move on. I suspect removing an experimental feature in an extension that is disabled by default and requires external library still requires an RFC? And according to the current rules of the game it cannot be removed in 5.5.1, but has to be removed in 5.6.0? -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Simplified Array API for extensions
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
On Wed, Apr 3, 2013 at 10:42 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Wed, Apr 3, 2013 at 5:42 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Wed, Apr 3, 2013 at 10:37 AM, Laruence larue...@php.net wrote: however, you are right, it's not a long time, so if objections becomes strong, I can revert it. this is exactly the kind of behavior why we changed from the commit first then revert when people complaining to the current approach, where we try to reach a concensus (via discussion on the mailing list or voting through RFCs) before introducing a change. I've gotta say, even though I disagree with the commit, writing an RFC for a new constant is a total WTF. There is absolutely no need for a RFC for it. Heck, even that initial curtesy mail was more then I would have expected. -Hannes I agree that not every small change requires an RFC (albeit a small change for one can seem a huge change for another) and I think that this is what I wrote originally. I'm glad that Laruence sent the original mail, I just wish that he would have waited another day or two before the commit. My reply was meant to address why it is a bad idea to shrug off the concerns and say that we can revert it later if the complains doesn't stop. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
On Thu, Apr 4, 2013 at 5:37 AM, Hannes Magnusson hannes.magnus...@gmail.com
wrote:
On Wed, Apr 3, 2013 at 2:00 PM, Stas Malyshev smalys...@sugarcrm.com
wrote:
Hi!
There is absolutely no need for a RFC for it.
Heck, even that initial curtesy mail was more then I would have
expected.
Agree, no need for full scale RFC for one constant. However, sending an
email to the list and actually waiting for feedback is exactly what I
would expect, especially dealing with stable version and feature that it
is not exactly clear what's going on with it. We're not talking about
writing RFCs for every minor change, we're talking about teamwork and
have members of the team be aware of the change and have time to discuss
it if needed. Nothing bad would happen if the same commit would land a
week later, after everybody is behind it and every detail is hashed out
(or not if turns out it is out of consensus). The point here is not to
impede work but to support teamwork.
There is a thin line between impeding work and team work for such a
trivial change.
This constant is actually really useful.
The entire feature is however unfortunately broken, but had it been in
a working shape then common. Really? Send an email and wait a week
before being able to write a testcase?
Anyway. Lets move on.
I suspect removing an experimental feature in an extension that is
disabled by default and requires external library still requires an
RFC?
And according to the current rules of the game it cannot be removed in
5.5.1, but has to be removed in 5.6.0?
Hey:
I am afraid yes, we can only remove it in 5.6.
now, since I already commit it (I am sorry for rushing then).
and you all agree that the constant is useful, so I think it's okey to
change the constant's name from curl_wrappers_enable
to curl_wrappers_enabled, and only defined when curl is built with
--with-curlwrappers.
then user can simply use if (defined(CURL_WRAPPERS_ENABLED) {}
after this, we can move on to write a RFC about remove the experiment
feature in 5.6, okey?
thanks
-Hannes
--
Laruence Xinchen Hui
http://www.laruence.com/
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
Did I just read that even though we have reasons to believe this is not a good addition that we are *still* going to launch 5.5 with it?
Re: [PHP-DEV] [RFC] Simplified Array API for extensions
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 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
On Thu, Apr 4, 2013 at 1:39 PM, Levi Morrison morrison.l...@gmail.comwrote: Did I just read that even though we have reasons to believe this is not a good addition that we are *still* going to launch 5.5 with it? where did you read that(not a good addition)? thanks -- Laruence Xinchen Hui http://www.laruence.com/
