Re: [PHP-DEV] PHP 7 installation issues.
On Thu, Jan 29, 2015 at 4:42 PM, Levi Morrison le...@php.net wrote: About the man page: what files do you have in php/man/man1 ? php.1 php-cgi.1 php-config.1 phpize.1 ^ Those four. Normally there are two more (phar.1 and phar.phar.1) from looking my 5.6.3 install. Aside from that I'm not sure what else could be different. I'm not very familiar with how man pages work, honestly; I just read them :) that seems ok, how do you prepend your MANPATH exactly? what's the output of MANPATH=/apps/php/7.0.0-dev/php/man:$MANPATH man php ? -- Ferenc Kovács @Tyr43l - http://tyrael.hu
[PHP-DEV] Re: Session: PS(mod)-create() or PS(mod)-read() parameter?
Hi all, On Thu, Jan 29, 2015 at 4:00 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: I would like to improve session save handler module API for PHP7. When new session data is created, some save handlers need to create new session data explicitly. e.g. RDBMS based save handler. New session module validates session data existence via PS(mod)-validate_sid(). When new data record is needed, RDBMS needs INSERT query to create a record. Since record existence is checked by validate_sid(), SELECT query in PS(mod)-read() that checks record existence is not required if there is proper API. Note: validate_sid() is there to enforce secure save handler implementation. One option is to have PS(mod)-create() for new session. The other is additional new_id flag parameter for PS(mod)-read(). Both change requires API change, but it wouldn't be issue for PHP7. Have new create API or new parameter for PS(mod)-read()? I don't care which. If there is no comment, I'll add new parameter since it's simpler. Comments are appreciated. Adding new_id parameter is simple. This is the patch. https://github.com/yohgaki/php-src/compare/master-session-new-api Please note that there is no session save handlers using the new_id flag yet, but the idea may be understood. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Session: PS(mod)-create() or PS(mod)-read() parameter?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 29/01/2015 08:00, Yasuo Ohgaki a écrit : If there is no comment, I'll add new parameter since it's simpler. Changing a function prototype is very hard to detect at buildtime, especially when playing with pointer. A new API seems really cleaner. Remi. -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlTJ7LEACgkQYUppBSnxahj89ACg5WnLubK6P/0+cYCb3MY1Gvzq GD0An05lk63xctI2YvWLjTwO46REgUnc =ILAE -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] pecl_http
Hi, On Thu, Jan 29, 2015 at 9:48 AM, Matteo Beccati p...@beccati.com wrote: Hi Andrey, On 28/01/2015 23:50, Andrey Andreev wrote: You're voting no because the FIG can't agree yet? They've been discussing this for *at least* an year and iirc the first PSR-7 coordinator gave up on it because he no longer believed in the end result. What does that tell us? That some actual work is finally being done now. Whether or not you, I or everyone else likes the direction it is going. I'm not saying that you should vote yes, but it's one thing to look at the FIG for opinions/suggestions/inspiration and completely different if you imply that they should dictate how a PHP core extension is implemented. Indeed. But I am aware that an effort to have common Request/Response interfaces is under way and I'd like to see how that goes (opinions/suggestions/inspiration) before marrying to a specific, possibly incompatible, implementation (pecl_http in core). PHP-FIG is not an authority and I too am quite annoyed by the excessive usage of the word standard when referring to a PSR. They are not standards, they are recommendations written by a self-appointed group of people and mostly for their own usage. A group of mostly very smart people indeed, and important figures in the PHP community too, but not an authority. Sure, S in PSR stands for Starndard, but R means Recommendation, but this is going slightly OT. It's not about whether we like the FIG's direction or what PSR stands for (which doesn't make sense btw) - that is indeed OT. My message was different: the PHP RFC process can't get blocked because of a third-party group, especially if your reasoning for that is to follow standards which aren't standards at all. Anyway, hopefully there will be more details on this RFC once voting is restarted so we don't have to have such silly arguments. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php7dev Vagrant box
Zitat von Rasmus Lerdorf ras...@lerdorf.com: As a follow-up to my PHP7 Homework post last week, here is a bit of spoon-feeding for all you lurkers on this list. https://atlas.hashicorp.com/rasmus/boxes/php7dev The description there should be fairly self-explanatory. If you have a computer running Linux, OSX or Windows and about 4G of disk space, heck install it on a $5 USB stick, then you don't have any excuses. It will takes less than 15 minutes of your time, and most of that is waiting for the download. Please use it to install your own applications or whatever random PHP applications out there you can find and help us track down issues. We have been plagued by bugs being found after initial releases because not enough people helped test in the past. Let's try to get ahead of them this time. -Rasmus The first command from your instructions there get me: $ vagrant box add rasmus/php7dev This command was not invoked properly. The help for this command is available below. -- Jan Schneider The Horde Project http://www.horde.org/ https://www.facebook.com/hordeproject -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 7 installation issues.
On 01/29/2015 03:49 AM, Levi Morrison wrote: When doing `make install` with a prefix of `/apps/php/7.0.0-dev` I get: Installing shared extensions: /apps/php/7.0.0-dev/lib/php/extensions/no-debug-non-zts-20141001/ Installing PHP CLI binary:/apps/php/7.0.0-dev/bin/ Installing PHP CLI man page: /apps/php/7.0.0-dev/php/man/man1/ Installing PHP CGI binary:/apps/php/7.0.0-dev/bin/ Installing PHP CGI man page: /apps/php/7.0.0-dev/php/man/man1/ Installing build environment: /apps/php/7.0.0-dev/lib/php/build/ Installing header files: /apps/php/7.0.0-dev/include/php/ Installing helper programs: /apps/php/7.0.0-dev/bin/ program: phpize program: php-config Installing man pages: /apps/php/7.0.0-dev/php/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /apps/php/7.0.0-dev/lib/php/ make[1]: *** [install-pear-installer] Error 255 make: *** [install-pear] Error 2 Hmm. I had that exact (I think) problem on building a checkout on Jan 14, but could not reproduce it no matter how hard I tried, that's why I didn't open a bug report - but apparently it's kind of valid. Some info for my machine: Debian GNU/Linux 7.8 (wheezy) x86_64 './configure' \ '--prefix=/usr/local/stow/php-7.0-master' \ '--with-config-file-path=/etc/php5/7.0-master' \ '--enable-fpm' \ '--with-fpm-user=www-data' \ '--with-fpm-group=www-data' \ '--with-gd' \ '--enable-zip' \ '--with-mysqli=mysqlnd' \ '--with-pdo-mysql=mysqlnd' \ '--enable-mbstring' \ '--with-curl' \ '--with-freetype-dir=/usr/include/freetype2' \ '--enable-gd-native-ttf' \ $@ Greetings, Florian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Session: PS(mod)-create() or PS(mod)-read() parameter?
Hi Remi, On Thu, Jan 29, 2015 at 5:17 PM, Remi Collet r...@fedoraproject.org wrote: If there is no comment, I'll add new parameter since it's simpler. Changing a function prototype is very hard to detect at buildtime, especially when playing with pointer. A new API seems really cleaner. Reasonable discussion. I'll prepare API version patch later. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV][RFC] Enable error_handler callback parameters to be passed by reference
Hi Thomas, On Thu, Jan 29, 2015 at 4:55 PM, Thomas Bley ma...@thomasbley.de wrote: I think you mean: function myErrorHandler( int $errno , string $errstr [, string $errfile [, int $errline [, array $errcontext [, string $extra_errstr ) Yes. We have these empty-call-filled-on-return parameters in preg_match(...$match) but I am not sure if it makes things more complicated than they should be. For me, changing $errstr to $errstr is the simplest thing to do. I agree. I would like to have this feature. Better log is better management. I don't care much about complexity, but simpler is better. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] php7dev Vagrant box
On Thu, Jan 29, 2015 at 9:57 AM, Jan Schneider j...@horde.org wrote: Zitat von Rasmus Lerdorf ras...@lerdorf.com: As a follow-up to my PHP7 Homework post last week, here is a bit of spoon-feeding for all you lurkers on this list. https://atlas.hashicorp.com/rasmus/boxes/php7dev The description there should be fairly self-explanatory. If you have a computer running Linux, OSX or Windows and about 4G of disk space, heck install it on a $5 USB stick, then you don't have any excuses. It will takes less than 15 minutes of your time, and most of that is waiting for the download. Please use it to install your own applications or whatever random PHP applications out there you can find and help us track down issues. We have been plagued by bugs being found after initial releases because not enough people helped test in the past. Let's try to get ahead of them this time. -Rasmus The first command from your instructions there get me: $ vagrant box add rasmus/php7dev This command was not invoked properly. The help for this command is available below. what version of vagrant are you using? (you can check via vagrant --version) adding boxes like that (username/boxname format instead of using the full url for the box) is only supported since vagrant 1.5 if you don't wanna upgrade you could try something like vagrant box add https://atlas.hashicorp.com/rasmus/boxes/php7dev vagrant init php7dev but probably easier to just upgrade -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
Hi Mike, Awesome work! On Thu, Jan 29, 2015 at 8:14 PM, Michael Wallner m...@php.net wrote: I’ve rewritten the RFC for pecl_http and hopefully addressed most of the things mentioned previously. I you still find anything lacking, please let me know, so I can expand the RFC accordingly. And of course, everything else is up for discussion. https://wiki.php.net/rfc/pecl_http The URL is this, right? -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
Hi Mike, On 29 Jan 2015, at 11:14, Michael Wallner m...@php.net wrote: I’ve rewritten the RFC for pecl_http and hopefully addressed most of the things mentioned previously. I you still find anything lacking, please let me know, so I can expand the RFC accordingly. The RFC is an improvement in that it covers more of *what* pecl/http is, but it still doesn’t answer the most important question: why? It still doesn’t answer any of the following key questions: * Why do we need pecl/http? * Why should pecl/http be merged into PHP core? * Why should pecl/http be enabled by default? * Why should we have our own HTTP API and not follow PSR-7? * What does it offer over PHP’s existing HTTP capabilities? * Why should we merge this rather than, say, filling in gaps in PHP’s HTTP capabilities? So, I think the RFC is still rather lacking. The Features section isn’t really any better than before, either. It only gives a sentence or two to each module, which isn’t terribly informative. Each module probably needs its own rationale, and a comparison to PHP’s existing facilities, as well. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] pecl_http
Hi, On Thu, Jan 29, 2015 at 12:52 PM, Matteo Beccati p...@beccati.com wrote: Hi Andrey, On 29/01/2015 10:41, Andrey Andreev wrote: It's not about whether we like the FIG's direction or what PSR stands for (which doesn't make sense btw) - that is indeed OT. My message was different: the PHP RFC process can't get blocked because of a third-party group, especially if your reasoning for that is to follow standards which aren't standards at all. Anyway, hopefully there will be more details on this RFC once voting is restarted so we don't have to have such silly arguments. I'm not sure why you're turning this into a crusade against FIG and PSRs. Your argument is valid, but I'm afraid that's the message you conveyed much louder than the actual argument itself. My last message was intended to clarify that this is *not* a rant about the FIG or PSRs, but a concern about proper reasoning in votes. I didn't want to have another reply because this is all off-topic at this point, but now you insist that I am in fact having a crusade against PHP-FIG - I'm not, sorry if that wasn't clear enough. Let's leave it at that please. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] pecl_http
Hi Andrey, On 29/01/2015 10:41, Andrey Andreev wrote: It's not about whether we like the FIG's direction or what PSR stands for (which doesn't make sense btw) - that is indeed OT. My message was different: the PHP RFC process can't get blocked because of a third-party group, especially if your reasoning for that is to follow standards which aren't standards at all. Anyway, hopefully there will be more details on this RFC once voting is restarted so we don't have to have such silly arguments. I'm not sure why you're turning this into a crusade against FIG and PSRs. Your argument is valid, but I'm afraid that's the message you conveyed much louder than the actual argument itself. I didn't ask to block the RFC. I simply voted no to the RFC and explained why I did that on the list, as it's expected from anyone who does. The vote has since been cancelled. The next time it is opened, I would love to read in the RFC why this implementation is better than any userland attempt at it, be it PSR-7 or not. Cheers -- Matteo Beccati Development Consulting - http://www.beccati.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] [DISCUSSION] pecl_http
Hi! I’ve rewritten the RFC for pecl_http and hopefully addressed most of the things mentioned previously. I you still find anything lacking, please let me know, so I can expand the RFC accordingly. And of course, everything else is up for discussion. Thanks, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] pecl_http
2015-01-29 14:07 GMT+01:00 Pavel Kouřil pajou...@gmail.com: On Wed, Jan 28, 2015 at 1:17 PM, Michael Wallner m...@php.net wrote: Hi, Discussion has been very low on this topic since it was proposed on August 19th, so I just opened the vote on the RFC whether to add pecl_http to the core. The vote will be open until about 12:00 UTC on Friday, February 6th. https://wiki.php.net/rfc/pecl_http#vote -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Hello, just one observation - would be the name of the classes and namespaces stay the same after merging? I personally find the lowercased namespace name kinda weird, given that most of code written in PHP I've seen is using CamelCase. Maybe there should be an RFC which would standardize naming and etc. for future features? Regards Pavel Kouril -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php +1 on that if the component getting merged. Would also be fine if the rest would follow PSR1+2 (for the public signatures only of course)
Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
On 29/01/15 12:32, Yasuo Ohgaki wrote: Hi Mike, Awesome work! On Thu, Jan 29, 2015 at 8:14 PM, Michael Wallner m...@php.net mailto:m...@php.net wrote: I’ve rewritten the RFC for pecl_http and hopefully addressed most of the things mentioned previously. I you still find anything lacking, please let me know, so I can expand the RFC accordingly. And of course, everything else is up for discussion. https://wiki.php.net/rfc/pecl_http The URL is this, right? Yes, of course! Bad mistake, sorry. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
* Why should we have our own HTTP API and not follow PSR-7? possible points: - PHP-FIG propose no implementations; pecl_http does - PHP-FIG focus on frameworks; pecl_http in core is useable without dependencies by every simple script - PSR-7 is a moving target; pecl_http exists for ten years - PSR-7 can be complementary to pecl_http not the other way around (c code can't use php code?) - native implementations should be faster -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
On 29 Jan 2015, at 12:18, Crypto Compress cryptocompr...@googlemail.com wrote: * Why should we have our own HTTP API and not follow PSR-7? possible points: - PHP-FIG propose no implementations; pecl_http does - native implementations should be faster I don’t see how that’s relevant: I’m talking here about the API, not the implementation. Why should PHP’s HTTP API not be PSR-7? - PHP-FIG focus on frameworks; pecl_http in core is useable without dependencies by every simple script Also irrelevant, there’s no reason it couldn’t use PSR-7’s API. - PSR-7 is a moving target; pecl_http exists for ten years Fair point. - PSR-7 can be complementary to pecl_http not the other way around (c code can't use php code?) Not necessarily true. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php7dev Vagrant box
Zitat von Ferenc Kovacs tyr...@gmail.com: On Thu, Jan 29, 2015 at 11:03 AM, Jan Schneider j...@horde.org wrote: _Zitat von Ferenc Kovacs tyr...@gmail.com:_ _On Thu, Jan 29, 2015 at 9:57 AM, Jan Schneider j...@horde.org wrote:_ _Zitat von Rasmus Lerdorf ras...@lerdorf.com:_ _As a follow-up to my PHP7 Homework post last week, here is a bit of spoon-feeding for all you lurkers on this list. https://atlas.hashicorp.com/_rasmus/boxes/php7dev_ _The description there should be fairly self-explanatory. If you have a computer running Linux, OSX or Windows and about 4G of disk space, heck install it on a $5 USB stick, then you don't have any excuses. It will takes less than 15 minutes of your time, and most of that is waiting for the download. Please use it to install your own applications or whatever random PHP applications out there you can find and help us track down issues. We have been plagued by bugs being found after initial releases because not enough people helped test in the past. Let's try to get ahead of them this time. -Rasmus__ __The first command from your instructions there get me: $ vagrant box add rasmus/php7dev This command was not invoked properly. The help for this command is available below.__ _ _ _ _ __what version of vagrant are you using? (you can check via vagrant --version)__ __adding boxes like that (username/boxname format instead of using the full url for the box) is only supported since vagrant 1.5__ __if you don't wanna upgrade you could try something like__ __vagrant box add https://atlas.hashicorp.com/rasmus/boxes/php7dev __ __vagrant init php7dev__ __but probably easier to just upgrade__ _ _ __--__ __Ferenc Kovács @Tyr43l - http://tyrael.hu__ _It's indeed 1.4, but that doesn't work with the full URL either. Upgrading is the way to go._ _agree, but out of curiosity, could you try the following with 1.4?:_ _vagrant box add rasmus/php7dev https://vagrantcloud.com/rasmus/boxes/php7dev/versions/0.0.2/providers/virtualbox.box --provider virtualbox_ _-- _ _Ferenc Kovács @Tyr43l - http://tyrael.hu_ Too late, I already upgraded. But 1.4.x is the version shipped with recent Ubunutu (and thus probably recent Debian), so you can easily test it there. - Jan Schneider The Horde Project http://www.horde.org/ https://www.facebook.com/hordeproject
Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
On 29/01/15 11:40, Andrea Faulds wrote: * Why do we need pecl/http? * Why should pecl/http be merged into PHP core? * Why should pecl/http be enabled by default? * Why should we have our own HTTP API and not follow PSR-7? * What does it offer over PHP’s existing HTTP capabilities? * Why should we merge this rather than, say, filling in gaps in PHP’s HTTP capabilities? On one hand third party packages are being pushed in place of the existing built in functions. Here a new set of built in functions are being proposed. Having used Apache for many years and now moved to Nginx as my 'interface', just where does this fit into the overall jigsaw. Using Nginx to handle the static stuff and only passing dynamic calls to php_fpm, just what http functionality is needed? The main reason for asking this question actually relates to implementing a server for tzdist which I can easily handle with the Nginx/php_fpm framework, and that should serve static pages until a change of version requires building a new data set. Is this the sort of process that can be handled totally within PHP and does that actually make sense where a large volume of static data is cached? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php7dev Vagrant box
On Thu, Jan 29, 2015 at 11:03 AM, Jan Schneider j...@horde.org wrote: Zitat von Ferenc Kovacs tyr...@gmail.com: On Thu, Jan 29, 2015 at 9:57 AM, Jan Schneider j...@horde.org wrote: Zitat von Rasmus Lerdorf ras...@lerdorf.com: As a follow-up to my PHP7 Homework post last week, here is a bit of spoon-feeding for all you lurkers on this list. https://atlas.hashicorp.com/*rasmus/boxes/php7dev* https://atlas.hashicorp.com/rasmus/boxes/php7dev *The description there should be fairly self-explanatory. If you have a computer running Linux, OSX or Windows and about 4G of disk space, heck install it on a $5 USB stick, then you don't have any excuses. It will takes less than 15 minutes of your time, and most of that is waiting for the download. Please use it to install your own applications or whatever random PHP applications out there you can find and help us track down issues. We have been plagued by bugs being found after initial releases because not enough people helped test in the past. Let's try to get ahead of them this time. -Rasmus* *The first command from your instructions there get me: $ vagrant box add rasmus/php7dev This command was not invoked properly. The help for this command is available below.* *what version of vagrant are you using? (you can check via vagrant --version)* *adding boxes like that (username/boxname format instead of using the full url for the box) is only supported since vagrant 1.5* *if you don't wanna upgrade you could try something like* *vagrant box add https://atlas.hashicorp.com/rasmus/boxes/php7dev https://atlas.hashicorp.com/rasmus/boxes/php7dev * *vagrant init php7dev* *but probably easier to just upgrade* *--* *Ferenc Kovács @Tyr43l - http://tyrael.hu http://tyrael.hu* It's indeed 1.4, but that doesn't work with the full URL either. Upgrading is the way to go. agree, but out of curiosity, could you try the following with 1.4?: vagrant box add rasmus/php7dev https://vagrantcloud.com/rasmus/boxes/php7dev/versions/0.0.2/providers/virtualbox.box --provider virtualbox -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] [VOTE] pecl_http
On Wed, Jan 28, 2015 at 1:17 PM, Michael Wallner m...@php.net wrote: Hi, Discussion has been very low on this topic since it was proposed on August 19th, so I just opened the vote on the RFC whether to add pecl_http to the core. The vote will be open until about 12:00 UTC on Friday, February 6th. https://wiki.php.net/rfc/pecl_http#vote -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Hello, just one observation - would be the name of the classes and namespaces stay the same after merging? I personally find the lowercased namespace name kinda weird, given that most of code written in PHP I've seen is using CamelCase. Maybe there should be an RFC which would standardize naming and etc. for future features? Regards Pavel Kouril -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 7 installation issues.
On Thu, Jan 29, 2015 at 3:49 AM, Levi Morrison le...@php.net wrote: When doing `make install` with a prefix of `/apps/php/7.0.0-dev` I get: Installing shared extensions: /apps/php/7.0.0-dev/lib/php/extensions/no-debug-non-zts-20141001/ Installing PHP CLI binary:/apps/php/7.0.0-dev/bin/ Installing PHP CLI man page: /apps/php/7.0.0-dev/php/man/man1/ Installing PHP CGI binary:/apps/php/7.0.0-dev/bin/ Installing PHP CGI man page: /apps/php/7.0.0-dev/php/man/man1/ Installing build environment: /apps/php/7.0.0-dev/lib/php/build/ Installing header files: /apps/php/7.0.0-dev/include/php/ Installing helper programs: /apps/php/7.0.0-dev/bin/ program: phpize program: php-config Installing man pages: /apps/php/7.0.0-dev/php/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /apps/php/7.0.0-dev/lib/php/ make[1]: *** [install-pear-installer] Error 255 make: *** [install-pear] Error 2 Hmm. Then prepending `/apps/php/7.0.0-dev/php/man` to my MANPATH, then doing `man php` I get this: No manual entry for php See 'man 7 undocumented' for help when manual pages are not available. I would have expected the man pages to work since that portion of the install script worked, but I suppose they could be related. In any case, it will be hard for me to test things until `make install` works properly. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php About pear: Nikita recently merged another piece(removing Assignment of new by reference) from https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7 so until somebody (me probably) fixes the pear installer you need --without-pear to your configure if you aren't using --disable-all. About the man page: what files do you have in php/man/man1 ? -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
On 1/29/15 6:40 AM, Andrea Faulds wrote: On 29 Jan 2015, at 12:18, Crypto Compress cryptocompr...@googlemail.com wrote: * Why should we have our own HTTP API and not follow PSR-7? possible points: - PHP-FIG propose no implementations; pecl_http does - native implementations should be faster I don’t see how that’s relevant: I’m talking here about the API, not the implementation. Why should PHP’s HTTP API not be PSR-7? - PHP-FIG focus on frameworks; pecl_http in core is useable without dependencies by every simple script Also irrelevant, there’s no reason it couldn’t use PSR-7’s API. - PSR-7 is a moving target; pecl_http exists for ten years Fair point. - PSR-7 can be complementary to pecl_http not the other way around (c code can't use php code?) Not necessarily true. -- Andrea Faulds http://ajf.me/ In my rainbows and ponies vision of the future, it would go something like this: 1) PSR-7 is approved. People use it. People love it. 2) Internals makes internal definitions of the interfaces from PSR-7, renamed to a PHP namespace but otherwise identical. Eg: \Php\Http\Message \Php\Http\Request \Php\Http\Response \Php\Http\ServerRequest FIG makes available an alternate set of interfaces that are PSR-7 but extent the internal ones for type hint compatibility. Someone (FIG, internals, me?) makes a user-space definition of the new internals interfaces as a BC layer. 3) Internals improves its userspace stream APIs such that the StreamInterface from PSR-7 can be retired completely. (It exists almost entirely as a way to avoid dealing with the PHP-native stream APIs.) 4) Internals adds a function/routine/thing to spawn a ServerRequest that is equivalent to the user-space code to create a PSR-7 ServerRequest out of the superglobals. It is, of course, faster than doing in userspace and also more standard. Internals also adds a send this response object to this stream (default stdout) routine. 5) Everyone switches over to using the Internals-named interfaces and ServerRequest builder. Because the interface is the same aside from the name this is about a 5 minute task per project and could be done by a small shell script. 6) Internals build a simple HTTP client that uses \Php\Http directly. It's probably not as powerful as Guzzle et al but easily extensible. Because user-space clients are already using those interfaces, that makes swapping the new Internals one in instead is a really easy task. Guzzle et al can convert to being extensions on the core one, all using the common interfaces. 7) The Ewoks, they dance! I don't expect it will happen exactly like that, of course, but the closer we can get to that sort of chain of events the better I think it will be for everyone. Note that the interface definition parts are separate from the writing of the HTTP client. I think it's important to address those two separately. SRP applies to RFCs just as much as code. :-) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 7 installation issues.
About the man page: what files do you have in php/man/man1 ? php.1 php-cgi.1 php-config.1 phpize.1 ^ Those four. Normally there are two more (phar.1 and phar.phar.1) from looking my 5.6.3 install. Aside from that I'm not sure what else could be different. I'm not very familiar with how man pages work, honestly; I just read them :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improvements to for-each implementation
Hi,
I've solved most of the reported problems and started working on RFC.
Nikta, please take a look into:
https://wiki.php.net/rfc/php7_foreach
https://github.com/php/php-src/pull/1034
and especially commit 15a23b1
Only iteration by value over plain objects is not completely consistent now.
However, the implementation may have bugs and other problems (your code
review may be very helpful).
I'm still working...
Thanks. Dmitry.
On Wed, Jan 28, 2015 at 7:59 AM, Dmitry Stogov dmi...@zend.com wrote:
I've created a branch and pull request for easier collaboration and
tracking.
https://github.com/php/php-src/pull/1034
It's the same diff I published yesterday. Nothing changed or added yet.
Thanks. Dmitry.
On Wed, Jan 28, 2015 at 1:36 AM, Nikita Popov nikita@gmail.com
wrote:
On Tue, Jan 27, 2015 at 5:55 PM, Dmitry Stogov dmi...@zend.com wrote:
Hi,
I'm working on a PoC, implementing the proposed behavior -
https://gist.github.com/dstogov/a311e8b0b2cabee4dab4
Only few PHPT tests had to be changed to confirm new behavior and
actually they started to behave as HHVM.
2 tests are still unfixed XFAILed. Foreach by reference is still need to
be improved to support different array modifications.
The patch makes ~1% improvement on Wordpress-3.6 (saving duplication and
destruction of 200 arrays on each request)
Thanks. Dmitry.
I quickly looked over the patch, some notes:
* 171: Can directly use GET_OP1_ZVAL_PTR_DEREF
* For iterator failures (exception) you use FREE_OP1_IF_VAR(). Is this
enough? If the object is a TMP_VAR, don't we have to free it as well?
* For objects it will still be possible to modify the hashtable during
iteration even in the _R case, correct? I assume we just don't care about
this edge case.
* 315: In RESET_RW you now always create a reference for VAR|CV operands.
However for the get_iterator case we don't need this, right?
* 328: In the non VAR|CV case SEPARTE_ARRAY is not used. As we're going
to change the IAP, this is probably necessary in this case as well.
* For RW iterator failures FREE_OP1_VAR_PTR() is used. This probably
leaks in the TMP case. (Same for the invalid argument case.)
What concerns me a bit is the new FETCH_RW implementation, because it no
longer checks the internal pointer against the external one. This
effectively means that foreach by reference behavior will be influenced a
lot by details of the hashtable implementation. An example:
$array = [0, 1, 2, 3, 4, 5, 6, 7];
unset($array[0], $array[1], $array[2], $array[3]);
foreach ($array as $ref) {
var_dump($ref);
//$array[42] = 42;
}
Without the commented line this will just print the numbers 4, 5, 6, 7.
If you uncomment the line it will only print 4. (Because the append caused
a rehash and arData was compacted, so the position now points past all
elements). The previous output would have been 4, 5, 6, 7, 42, which is
closer to what you would expect. Maybe better to keep the pos !=
nInternalPointer code?
Thanks,
Nikita
[PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http
On 29 01 2015, at 12:14, Michael Wallner m...@php.net wrote: Hi! I’ve rewritten the RFC for pecl_http and hopefully addressed most of the things mentioned previously. I you still find anything lacking, please let me know, so I can expand the RFC accordingly. And of course, everything else is up for discussion. Just a tiny note: I expanded the features section a bit. https://wiki.php.net/rfc/pecl_http#features https://wiki.php.net/rfc/pecl_http#features Regards, Mike
Re: [PHP-DEV] Use of {} with member.
Hi,
On Thu, Jan 29, 2015 at 11:32 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi all,
I came across with bug #68947 https://bugs.php.net/bug.php?id=68947
and realized small inconsistency.
http://3v4l.org/ldZKl
$obj-${array[$key]}; // Syntax error
$obj-{$array[$key]}; // Works
$obj-${key}; // E_NOTICE. Does not work
$obj-{$key}; // Works
echo ${array[$key]}; // Works
echo {$array[$key]}; // Works
Of course, script/string parsing aren't the same. Are there technical
reasons
why ${value} is not allowed? If there are, we may encourage
echo {$array[$key]}; // Works
rather than
echo ${array[$key]}; // Works
Is somebody actually recommending the latter form? I'm surprised that
it even works ... that should be a syntax error IMO.
Cheers,
Andrey.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Use of {} with member.
Hi Andrey,
On Fri, Jan 30, 2015 at 6:43 AM, Andrey Andreev n...@devilix.net wrote:
Is somebody actually recommending the latter form? I'm surprised that
it even works ... that should be a syntax error IMO.
Do you mean
echo ${array[$key]}; // Works
should be errror?
This form is common in shell scripting.
http://tldp.org/LDP/abs/html/parameter-substitution.html
I'm using it regularly. I guess many users expect following forms to work.
$obj-${array[$key]}; // Syntax error
$obj-${key}; // E_NOTICE. Does not work
What others expect?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
Hi all, On Thu, Jan 29, 2015 at 9:18 PM, Crypto Compress cryptocompr...@googlemail.com wrote: possible points: - PHP-FIG propose no implementations; pecl_http does - PHP-FIG focus on frameworks; pecl_http in core is useable without dependencies by every simple script - PSR-7 is a moving target; pecl_http exists for ten years - PSR-7 can be complementary to pecl_http not the other way around (c code can't use php code?) - native implementations should be faster General pros - PHP is made for Web. API like pecl_http should be included by default. - Script implementation and module implementation can co-exists. Example is mail/imap. Now I understand why many people dislike this proposal probably. Native module/script implementations may exist both. New module may be added/replaced at any time if it's required/reasonable. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
[PHP-DEV] Use of {} with member.
Hi all,
I came across with bug #68947 https://bugs.php.net/bug.php?id=68947
and realized small inconsistency.
http://3v4l.org/ldZKl
$obj-${array[$key]}; // Syntax error
$obj-{$array[$key]}; // Works
$obj-${key}; // E_NOTICE. Does not work
$obj-{$key}; // Works
echo ${array[$key]}; // Works
echo {$array[$key]}; // Works
Of course, script/string parsing aren't the same. Are there technical
reasons
why ${value} is not allowed? If there are, we may encourage
echo {$array[$key]}; // Works
rather than
echo ${array[$key]}; // Works
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] Use of {} with member.
Hi Yasuo,
On 29 Jan 2015, at 22:14, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Andrey,
On Fri, Jan 30, 2015 at 6:43 AM, Andrey Andreev n...@devilix.net wrote:
Is somebody actually recommending the latter form? I'm surprised that
it even works ... that should be a syntax error IMO.
Do you mean
echo ${array[$key]}; // Works
should be errror?
This form is common in shell scripting.
http://tldp.org/LDP/abs/html/parameter-substitution.html
I'm using it regularly. I guess many users expect following forms to work.
$obj-${array[$key]}; // Syntax error
$obj-${key}; // E_NOTICE. Does not work
What others expect?
I would expect that anything within ${} works the same as it does outside it.
Having $obj-${array[$key]} do something different to $key = array[$key],
$obj-${$key} would make no sense to me.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Use of {} with member.
Hi all,
On Fri, Jan 30, 2015 at 8:51 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 01/29/2015 01:32 PM, Yasuo Ohgaki wrote:
Hi all,
I came across with bug #68947 https://bugs.php.net/bug.php?id=68947
and realized small inconsistency.
http://3v4l.org/ldZKl
$obj-${array[$key]}; // Syntax error
$obj-{$array[$key]}; // Works
$obj-${key}; // E_NOTICE. Does not work
$obj-{$key}; // Works
echo ${array[$key]}; // Works
echo {$array[$key]}; // Works
Of course, script/string parsing aren't the same. Are there technical
reasons
why ${value} is not allowed? If there are, we may encourage
echo {$array[$key]}; // Works
rather than
echo ${array[$key]}; // Works
That all seems expected to me. The original point of that bug report is
the BC break due to the uniform variable rfc. The change makes sense,
but just for the record, I have installed about 10 popular, and a couple
of not-so-popular, PHP apps and tested them on PHP 7 over the past week
and this was the only BC break that affected that set of 10 apps.
See:
https://github.com/rlerdorf/avalon/commit/18847d0fe65381977397271c79e04dde72ef86f8
It is listed as a bullet point in a sea of other bullet points in the
UPGRADING file:
. Indirect variable, property and method references are now
interpreted with left-to-right semantics. See details in:
https://wiki.php.net/rfc/uniform_variable_syntax#semantic_differences_in_existing_syntax
But we probably need a section devoted to BC breaks that includes some
real-world code examples.
I agree.
Since ${var} works in quoted string just like shells, there may be
confusion. Extending
http://php.net/manual/en/language.variables.basics.php
or adding new section might be good.
I haven't checked variable variable fully. There may be misbehavior
http://3v4l.org/vmKvi
Apparently, HHVM have missed to support multiple variable variable
reference.
Heads up HHVM folks!
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] Use of {} with member.
Hi Andrea,
On Fri, Jan 30, 2015 at 7:17 AM, Andrea Faulds a...@ajf.me wrote:
I would expect that anything within ${} works the same as it does outside
it. Having $obj-${array[$key]} do something different to $key =
array[$key], $obj-${$key} would make no sense to me.
Good point! I forgot about variable variable.
PHP works as follows now.
http://3v4l.org/dpbES
Andrey, the reason why you are surprised is probably because of this
// echo ${obj-var}; // Syntax error
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] Use of {} with member.
On 01/29/2015 01:32 PM, Yasuo Ohgaki wrote:
Hi all,
I came across with bug #68947 https://bugs.php.net/bug.php?id=68947
and realized small inconsistency.
http://3v4l.org/ldZKl
$obj-${array[$key]}; // Syntax error
$obj-{$array[$key]}; // Works
$obj-${key}; // E_NOTICE. Does not work
$obj-{$key}; // Works
echo ${array[$key]}; // Works
echo {$array[$key]}; // Works
Of course, script/string parsing aren't the same. Are there technical
reasons
why ${value} is not allowed? If there are, we may encourage
echo {$array[$key]}; // Works
rather than
echo ${array[$key]}; // Works
That all seems expected to me. The original point of that bug report is
the BC break due to the uniform variable rfc. The change makes sense,
but just for the record, I have installed about 10 popular, and a couple
of not-so-popular, PHP apps and tested them on PHP 7 over the past week
and this was the only BC break that affected that set of 10 apps.
See:
https://github.com/rlerdorf/avalon/commit/18847d0fe65381977397271c79e04dde72ef86f8
It is listed as a bullet point in a sea of other bullet points in the
UPGRADING file:
. Indirect variable, property and method references are now
interpreted with left-to-right semantics. See details in:
https://wiki.php.net/rfc/uniform_variable_syntax#semantic_differences_in_existing_syntax
But we probably need a section devoted to BC breaks that includes some
real-world code examples.
-Rasmus
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] Use caller keyword, to access object caller.
Usually it is solved sending the $this instance to class C constructor and
C object storing it in some attribute, solving the problem. I don't think a
new keyword would help.
Juan Basso
On Thu, Jan 29, 2015 at 9:53 PM, S.A.N ua.san.a...@gmail.com wrote:
The reason for creating circular references, usually due to the need to
bind objects.
But this relationship can often be obtained from the context of the call.
It will be very convenient to have a keyword that will return reference to
an object, which caused this object.
Sorry for my English, I'm not a native speaker.
A simple example below shows the behavior that we need.
?php
class A
{
public function __construct() {
$this-object = new C;
}
}
class B
{
public function __construct() {
$this-object = new C;
}
}
class C
{
public function getCaller() {
return caller::class;
}
}
$a = new A;
$b = new B;
$c = new C;
$a-object-getCaller(); // return A
$b-object-getCaller(); // return B
$c-getCaller(); // Fatal Error - undefined caller context
?
Create a new keyword can cause problems with backward compatibility...
Perhaps you can solve a problem to using an existing keyword?
Thank you for any feedback.
Re: [PHP-DEV] Use caller keyword, to access object caller.
I will clarify the benefits of the keyword.
Single instance of the class can reused in different contexts calls.
?php
class A
{
public $object;
}
class B
{
public $object;
}
class C
{
public function getCaller() {
return caller::class;
}
}
$a = new A;
$b = new B;
$c = new C;
$a-object = $c;
$b-object = $c;
$a-object-getCaller(); // return A
$b-object-getCaller(); // return B
$c-getCaller(); // Fatal Error - undefined caller context
?
2015-01-30 5:50 GMT+02:00 Juan Basso jrba...@gmail.com:
Usually it is solved sending the $this instance to class C constructor and
C object storing it in some attribute, solving the problem. I don't think a
new keyword would help.
Juan Basso
On Thu, Jan 29, 2015 at 9:53 PM, S.A.N ua.san.a...@gmail.com wrote:
The reason for creating circular references, usually due to the need to
bind objects.
But this relationship can often be obtained from the context of the call.
It will be very convenient to have a keyword that will return reference to
an object, which caused this object.
Sorry for my English, I'm not a native speaker.
A simple example below shows the behavior that we need.
?php
class A
{
public function __construct() {
$this-object = new C;
}
}
class B
{
public function __construct() {
$this-object = new C;
}
}
class C
{
public function getCaller() {
return caller::class;
}
}
$a = new A;
$b = new B;
$c = new C;
$a-object-getCaller(); // return A
$b-object-getCaller(); // return B
$c-getCaller(); // Fatal Error - undefined caller context
?
Create a new keyword can cause problems with backward compatibility...
Perhaps you can solve a problem to using an existing keyword?
Thank you for any feedback.
[PHP-DEV] Use caller keyword, to access object caller.
The reason for creating circular references, usually due to the need to
bind objects.
But this relationship can often be obtained from the context of the call.
It will be very convenient to have a keyword that will return reference to
an object, which caused this object.
Sorry for my English, I'm not a native speaker.
A simple example below shows the behavior that we need.
?php
class A
{
public function __construct() {
$this-object = new C;
}
}
class B
{
public function __construct() {
$this-object = new C;
}
}
class C
{
public function getCaller() {
return caller::class;
}
}
$a = new A;
$b = new B;
$c = new C;
$a-object-getCaller(); // return A
$b-object-getCaller(); // return B
$c-getCaller(); // Fatal Error - undefined caller context
?
Create a new keyword can cause problems with backward compatibility...
Perhaps you can solve a problem to using an existing keyword?
Thank you for any feedback.
Re: [PHP-DEV] Use caller keyword, to access object caller.
Yes.
But this creates a static link that will not be constantly changing context
to the calls, the keyword will give a dynamic abstract communication.
2015-01-30 5:50 GMT+02:00 Juan Basso jrba...@gmail.com:
Usually it is solved sending the $this instance to class C constructor and
C object storing it in some attribute, solving the problem. I don't think a
new keyword would help.
Juan Basso
On Thu, Jan 29, 2015 at 9:53 PM, S.A.N ua.san.a...@gmail.com wrote:
The reason for creating circular references, usually due to the need to
bind objects.
But this relationship can often be obtained from the context of the call.
It will be very convenient to have a keyword that will return reference to
an object, which caused this object.
Sorry for my English, I'm not a native speaker.
A simple example below shows the behavior that we need.
?php
class A
{
public function __construct() {
$this-object = new C;
}
}
class B
{
public function __construct() {
$this-object = new C;
}
}
class C
{
public function getCaller() {
return caller::class;
}
}
$a = new A;
$b = new B;
$c = new C;
$a-object-getCaller(); // return A
$b-object-getCaller(); // return B
$c-getCaller(); // Fatal Error - undefined caller context
?
Create a new keyword can cause problems with backward compatibility...
Perhaps you can solve a problem to using an existing keyword?
Thank you for any feedback.
[PHP-DEV] Is it a good idea to have a strict mode?
Hi! I'm wondering if it would be a good idea to have a `strict` mode in PHP. Many language have them and it is a good idea. I think it should be a bit different in PHP, it should encourage the following things: - Avoid deprecated things, it should throw an exception. - Avoid explicit conversions of undefined constants to strings. - Anything else that could make run-time slower *or* bad practice. ```php use strict; var_dump(FOOBAR); // should throw an exception, undefined constant. ``` Good idea? Cheers, -- César D. Rodas Open Source developer +595-983-161124 PGP: F9ED A265 A3AB C8A1 D145 7368 158A 0336 C707 0AA6 signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Is it a good idea to have a strict mode?
Hi Cesar, On Fri, Jan 30, 2015 at 2:16 PM, César Rodas ce...@rodas.me wrote: I'm wondering if it would be a good idea to have a `strict` mode in PHP. Many language have them and it is a good idea. I think it should be a bit different in PHP, it should encourage the following things: - Avoid deprecated things, it should throw an exception. - Avoid explicit conversions of undefined constants to strings. - Anything else that could make run-time slower *or* bad practice. ```php use strict; var_dump(FOOBAR); // should throw an exception, undefined constant. ``` We have error_reporting INI for this purpose. Users may be strict or lazy for errors by the INI setting. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
[PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http
On Thu, Jan 29, 2015 at 8:14 PM, Michael Wallner m...@php.net wrote: I’ve rewritten the RFC for pecl_http and hopefully addressed most of the things mentioned previously. I you still find anything lacking, please let me know, so I can expand the RFC accordingly. And of course, everything else is up for discussion. Hi Mike :) I'd like to chime in on the discussion ... 1. There is a lot of *really* useful functionality in pecl/http that IMO should be bundled with the standard PHP distribution. This, to me, means things like parsing functionality that is conspicuously absent in a web-first language like PHP. HTTP messages, cookies, header parameters, multipart/form-data ... these are all standard HTTP elements for which we have no compiled parsing capabilities in the standard distribution. Adding this functionality in ext/http would be an instant win for my own work and I'm sure for many others as well. Moreover, parsing is the type of functionality that *really* benefits from being compiled as compared to happening in userland. Finally, this type of functionality is pretty vanilla and straightforward -- there is little room for stylistic disagreements in APIs and implementations. No one is going to complain that a multipart/form-data parser API is zomg so bad I need to tweet my frustration about #php right now. If it parses data how it's supposed to it's generally good enough. These are the kinds of things that ought to be bundled with the standard PHP distribution. They'd be a win for everyone and shouldn't realistically upset or confuse anyone. 2. There is some functionality here that isn't HTTP-specific and should exist in other extensions. I'm talking specifically here about the Encoding\Stream things. In fact, I had planned to PR essentially the same thing for ext/zlib between now and the 7 feature freeze. This is functionality that isn't specific to HTTP and belongs in ext/zlib, especially considering it relies on the zlib dependencies in the first place. I don't think it's a good idea to do this. It's missing functionality in another extension -- it should be PR'd and included there. PHP is well-known for its perceived lack of direction and this kind of overlap is exactly what people point to when they denigrate the language. If we already have these extensions lets update them instead of adding more extensions to cover holes in the existing ones. I'd personally prefer to see new development/inclusions take the wide view of the distribution as one whole PHP and not an incoherent mish-mash of overlapping extensions. 3. There is some functionality here that IMO belongs in pecl/ and not ext/ There are a lot of extras here. PHP's existing HTTP functionality is already spread all over the map and bundling this additional functionality certainly won't help to mitigate that. This ties in somewhat with my previous point, but ... we have superglobals, ext/curl, file_get_contents(), etc. Do we really need to bundle another extension that depends on curl to make HTTP requests? Do we really need to bring in two other pecl libs as hard dependencies for this? I don't really see enough benefit here to muddy the waters in such a way. Beyond this, http requests are IO-bound transactions ... this is something that can be done quite well (and is already) with existing userland libraries without incurring significant performance degradation. I don't see the need for all this extra stuff to add functionality that we already have. 4. There is some functionality here that will likely upset some people because it's subjective I'm speaking specifically about type abstractions like Message (and friends). This is functionality that provides very little performance benefit from being compiled and causes all sorts of disagreement and bikeshedding over API details. Obviously there's the whole PSR-7 thing happening right now which will be subjugated to any bundled HTTP abstractions in the standard distribution. While I personally have a lot of real problems with the API the FIG people are pushing, we certainly won't be making friends by adding a de facto standard HTTP API to the language with which they disagree. These are APIs which should be carefully considered at a community level in a web-first language. Short of that kind of consensus, I don't see how it's a good idea to bundle that kind of API with the rest of the language. ... So, in summary: If I had to take all of pecl/http or none of pecl/http right now ... I would vote, no, because while I want (and need) the capabilities from #1, I believe the associated drawbacks are too extensive to bring all the extra baggage into the standard PHP distribution. Thanks to anyone who read this phonebook of a mail all the way to the bottom! -Daniel
Re: [PHP-DEV] Use caller keyword, to access object caller.
On 01/29/2015 10:30 PM, S.A.N wrote:
I will clarify the benefits of the keyword.
Single instance of the class can reused in different contexts calls.
?php
class A
{
public $object;
}
class B
{
public $object;
}
class C
{
public function getCaller() {
return caller::class;
}
}
$a = new A;
$b = new B;
$c = new C;
$a-object = $c;
$b-object = $c;
$a-object-getCaller(); // return A
$b-object-getCaller(); // return B
$c-getCaller(); // Fatal Error - undefined caller context
?
This seems like an extremely bad idea to do in the first place. Code in
class C should function the same whether it was called from $a or $b.
If it should vary, that should be made explicit in the object's
construction and you have DIFFERENT instances of it.
Having an object that behaves differently depending on an implicit
relationship with where it happened to be called from is full of all
kinds of impossible to debug magic. I don't even know how you'd unit
test it. I can think of no use case where this wouldn't cause only
problems.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Use caller keyword, to access object caller.
De : Larry Garfield [mailto:la...@garfieldtech.com] Having an object that behaves differently depending on an implicit relationship with where it happened to be called from is full of all kinds of impossible to debug magic. I don't even know how you'd unit test it. I can think of no use case where this wouldn't cause only problems. The only use case I can think of is to enforce access restriction (an alternative to 'friend' classes), faster than using debug_backtrace(). But I would prefer really implementing friend classes/namespaces. @S.A.N: you can already determine the caller using debug_backtrace(). Slow and inconvenient, but it works. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
Hi Daniel! On 30 01 2015, at 07:28, Daniel Lowrey rdlow...@php.net wrote: Hi Mike :) I'd like to chime in on the discussion ... 1. There is a lot of *really* useful functionality in pecl/http that IMO should be bundled with the standard PHP distribution. This, to me, means things like parsing functionality that is conspicuously absent in a web-first language like PHP. HTTP messages, cookies, header parameters, multipart/form-data ... these are all standard HTTP elements for which we have no compiled parsing capabilities in the standard distribution. Adding this functionality in ext/http would be an instant win for my own work and I'm sure for many others as well. Moreover, parsing is the type of functionality that *really* benefits from being compiled as compared to happening in userland. Finally, this type of functionality is pretty vanilla and straightforward -- there is little room for stylistic disagreements in APIs and implementations. No one is going to complain that a multipart/form-data parser API is zomg so bad I need to tweet my frustration about #php right now. If it parses data how it's supposed to it's generally good enough. These are the kinds of things that ought to be bundled with the standard PHP distribution. They'd be a win for everyone and shouldn't realistically upset or confuse anyone. 2. There is some functionality here that isn't HTTP-specific and should exist in other extensions. I'm talking specifically here about the Encoding\Stream things. In fact, I had planned to PR essentially the same thing for ext/zlib between now and the 7 feature freeze. This is functionality that isn't specific to HTTP and belongs in ext/zlib, especially considering it relies on the zlib dependencies in the first place. I don't think it's a good idea to do this. It's missing functionality in another extension -- it should be PR'd and included there. PHP is well-known for its perceived lack of direction and this kind of overlap is exactly what people point to when they denigrate the language. If we already have these extensions lets update them instead of adding more extensions to cover holes in the existing ones. I'd personally prefer to see new development/inclusions take the wide view of the distribution as one whole PHP and not an incoherent mish-mash of overlapping extensions. 3. There is some functionality here that IMO belongs in pecl/ and not ext/ There are a lot of extras here. PHP's existing HTTP functionality is already spread all over the map and bundling this additional functionality certainly won't help to mitigate that. This ties in somewhat with my previous point, but ... we have superglobals, ext/curl, file_get_contents(), etc. Do we really need to bundle another extension that depends on curl to make HTTP requests? Do we really need to bring in two other pecl libs as hard dependencies for this? I don't really see enough benefit here to muddy the waters in such a way. Beyond this, http requests are IO-bound transactions ... this is something that can be done quite well (and is already) with existing userland libraries without incurring significant performance degradation. I don't see the need for all this extra stuff to add functionality that we already have. 4. There is some functionality here that will likely upset some people because it's subjective I'm speaking specifically about type abstractions like Message (and friends). This is functionality that provides very little performance benefit from being compiled and causes all sorts of disagreement and bikeshedding over API details. Obviously there's the whole PSR-7 thing happening right now which will be subjugated to any bundled HTTP abstractions in the standard distribution. While I personally have a lot of real problems with the API the FIG people are pushing, we certainly won't be making friends by adding a de facto standard HTTP API to the language with which they disagree. These are APIs which should be carefully considered at a community level in a web-first language. Short of that kind of consensus, I don't see how it's a good idea to bundle that kind of API with the rest of the language. ... So, in summary: If I had to take all of pecl/http or none of pecl/http right now ... I would vote, no, because while I want (and need) the capabilities from #1, I believe the associated drawbacks are too extensive to bring all the extra baggage into the standard PHP distribution. Thanks to anyone who read this phonebook of a mail all the way to the bottom! Thank you for taking the time to make your opinion public on internals, I appreciate. PHP should definitely take care to provide a reasonable API, but there’ll never be satisfaction for everyone. I think PHP is, and should be, a language where you’re more successful in getting things done, instead of having to do it right in one way only. This is not the end of the
[PHP-DEV] [RFC] Fix foreach behavior
Hi, I'd like to start discussion about fixing inconsistent foreach statement behavior. The implementation is almost done. It not only fixes inconsistencies in a defined by RFC way but also improves performance in most usual cases, because now foreach by value over array doesn't require array duplication. https://wiki.php.net/rfc/php7_foreach https://github.com/php/php-src/pull/1034 I'm going to continue work on implementation improvement and may be fixing related behavior of some internal functions when they used on array iterated by foreach by reference (e.g. array_unshift()). However, the conceptual behavior defined in RFC is not going to be changed anymore. Thanks. Dmitry.
Re: [PHP-DEV] Use of {} with member.
Hi,
On Fri, Jan 30, 2015 at 12:49 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Andrea,
On Fri, Jan 30, 2015 at 7:17 AM, Andrea Faulds a...@ajf.me wrote:
I would expect that anything within ${} works the same as it does outside
it. Having $obj-${array[$key]} do something different to $key =
array[$key], $obj-${$key} would make no sense to me.
Good point! I forgot about variable variable.
PHP works as follows now.
http://3v4l.org/dpbES
Andrey, the reason why you are surprised is probably because of this
// echo ${obj-var}; // Syntax error
Not entirely ... I just have it as a rule of thumb that if it's not
valid code with nothing around it, I shouldn't expect it to be valid
inside curly braces (excluding the semicolon of course). Pretty much
what Andrea said ...
?php array['foo']; ? is a syntax error, so I don't expect
${array['foo']} to be valid either. In fact, I just checked and it's
not: http://3v4l.org/B6kdv
echo ${array['foo']}; probably works only because of how variables
are parsed inside double quotes.
Cheers,
Andrey.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
