RE: [PHP-DEV] Voting periods
That's what Ralf and I suggested all along. By the way, the problem is that most of the web developers don't know anything about IT. I guess most of them use Windows (and you can't expect a Windows user to compile stuff), and the majority of the other half uses Ubuntu and never even saw the shell, they're using Ubuntu Software Centre. I'm not talking about those who go to conferences, but the vast majority of PHP coders who never wrote a single bit of native code and never had to compile anything. r1pp3rj4ck From: Stas Malyshev Sent: 30/01/2013 07:04 To: Larry Garfield Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Voting periods Hi! down. Right or wrong, good or bad, the gulf between PHP developer and C developer is *huge*, and doing anything at all with the PHP engine, We're not talking here writing code in C. We're talking here typing configure in shell, hitting enter, then typing make in shell, then hitting enter. It's not really *that* hard. OK, there are all kinds of envt problems and so on that could happen, but on standard Linux with standard libs that's pretty much it. But if even that is too hard, how about making something like spec file for RPM and a script that d/ls a snapshot and then builds a RPM from it? Installing RPM shouldn't be too hard? -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting periods
That's what Ralf and I suggested all along. By the way, the problem is that most of the web developers don't know anything about IT. I guess most of them use Windows (and you can't expect a Windows user to compile stuff), and the majority of the other half uses Ubuntu and never even saw the shell, they're using Ubuntu Software Centre. I'm not talking about those who go to conferences, but the vast majority of PHP coders who never wrote a single bit of native code and never had to compile anything. Not meaning to sound obnoxious, but are those kind of developers really likely to be able to give useful enough feedback that their testing nightly builds would be valuable? Surely a developer who doesn't know how to use the shell is going to be limited in what level of detail they can provide, potentially making the bug fixing process significantly more difficult. I'm no C developer, most of my work is in PHP - but I've never found it a struggle to compile PHP, MySQL or any of their associated libraries.
Re: [PHP-DEV] Voting periods
Dan, I'm a PHP developer myself too and I always compile PHP and Apache for my own (PostgreSQL is good for me as it's packaged for Archlinux). But the majority is just dumb. And you're right about the bug reports, lots of them would be just like it doesn't work because of reasons. But they'd at least try and we still could extract some valuable information from that. r1pp3rj4ck On Wed, Jan 30, 2013 at 9:47 AM, Dan Cryer d...@dancryer.com wrote: That's what Ralf and I suggested all along. By the way, the problem is that most of the web developers don't know anything about IT. I guess most of them use Windows (and you can't expect a Windows user to compile stuff), and the majority of the other half uses Ubuntu and never even saw the shell, they're using Ubuntu Software Centre. I'm not talking about those who go to conferences, but the vast majority of PHP coders who never wrote a single bit of native code and never had to compile anything. Not meaning to sound obnoxious, but are those kind of developers really likely to be able to give useful enough feedback that their testing nightly builds would be valuable? Surely a developer who doesn't know how to use the shell is going to be limited in what level of detail they can provide, potentially making the bug fixing process significantly more difficult. I'm no C developer, most of my work is in PHP - but I've never found it a struggle to compile PHP, MySQL or any of their associated libraries.
Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context
Gustavo Lopes wrote: I've opened the vote for the remove calls from incompatible context RFC: https://wiki.php.net/rfc/incompat_ctx#vote FINALLY realised why this was an itch I had to scratch. Why just pick on one aspect of E_STRICT ? Surely the end point should be removing all of the 'advisory warnings' blocked by E_STRICT rather than having a vote on each one. Flag as depricated ready to be removed in PHP6. So the discussion SHOULD be on what else should be removed in PHP6 ? -- 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] [VOTE] Deprecate and remove calls from incompatible context
On Wed, Jan 30, 2013 at 10:50 AM, Lester Caine les...@lsces.co.uk wrote: Gustavo Lopes wrote: I've opened the vote for the remove calls from incompatible context RFC: https://wiki.php.net/rfc/**incompat_ctx#votehttps://wiki.php.net/rfc/incompat_ctx#vote FINALLY realised why this was an itch I had to scratch. Why just pick on one aspect of E_STRICT ? Surely the end point should be removing all of the 'advisory warnings' blocked by E_STRICT rather than having a vote on each one. Flag as depricated ready to be removed in PHP6. So the discussion SHOULD be on what else should be removed in PHP6 ? as I mentioned before in another thread back in the pre 5.3 days E_STRICT was indeed used in some cases for the same purposes as what E_DEPRECATED does now, but there are exceptions so these should be reviewed case by case basis for deprecation/removal instead of replacing every E_STRICT with E_DEPRECATED. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
RE: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
XDebug together with an opcode cache is always a shaky thing and not something we should be too concerned about. You would never want to run both in production. It would be good if they didn't clobber each other for dev environment purposes, but I am sure we can figure that out. This is the kind of info the RFC (and then user doc) should have. It should be easy to implement the same behavior we have with Zend Debugger today also with Xdebug. The debugger essentially intercepts the compile() callback before Optimizer+, and if it determines that the present request should run through the debugger - it bypasses the Optimizer+ altogether and calls directly into zend_compile_file(). I'll update the RFC that it should be possible to integrate it nicely with any other modules. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ZTS - why are you using it?
Stas Malyshev wrote: The TS model in php should be redesigned in the next major version, instead of simply giving it up. Again, I'd not mind seeing this redesign, but do we have somebody who's actually going to do that? Ignoring the problem of 'someone to do it', in this age of multi-core systems, the idea of sending requests to a database server while building the page is an area where threading could provide a speed gain in returning a page? Something else to go on the wish list for PHP6? -- 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] ZTS - why are you using it?
On Wed, Jan 30, 2013 at 11:33 AM, Lester Caine les...@lsces.co.uk wrote: Stas Malyshev wrote: The TS model in php should be redesigned in the next major version, instead of simply giving it up. Again, I'd not mind seeing this redesign, but do we have somebody who's actually going to do that? Ignoring the problem of 'someone to do it', in this age of multi-core systems, the idea of sending requests to a database server while building the page is an area where threading could provide a speed gain in returning a page? Not really, async queries are way better and easier to deal with. Even if some OS implementation uses thread under the hood, it is totally hidden from an API point of view. -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] About PTY
Hi, I wonder if PHP supports PTY? I see old codes (from 2004 to 2010) using proc_open with $descriptors = [[0 = 'pty']] for example. When I try, I have an error because PTY seems to not be supported. ./configure does not propose me to --enable-pty as I have seen in some related posts. Thanks for the help, Best regards. -- Ivan Enderlin Developer of Hoa http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About PTY
On Wed, Jan 30, 2013 at 11:51 AM, Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net wrote: Hi, I wonder if PHP supports PTY? I see old codes (from 2004 to 2010) using proc_open with $descriptors = [[0 = 'pty']] for example. When I try, I have an error because PTY seems to not be supported. ./configure does not propose me to --enable-pty as I have seen in some related posts. Hi, based on http://lxr.php.net/xref/PHP_TRUNK/ext/standard/proc_open.c#653 and http://lxr.php.net/xref/PHP_TRUNK/ext/standard/proc_open.c#64 (notice the 0 ) I would say it isn't supported anymore. wez turned that off 9 years ago: https://github.com/php/php-src/commit/bd818c0118ba406d82f901d4f97a134727440df4 -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
On 1/17/2013 12:20 PM, Clint Priest wrote: I'm happy to say that Property Accessors is ready for a vote for inclusion in 5.5 release. Nikita and I (as well as Stas a bit) have all been working hard to make this happen for 5.5, voting and the specifications are here: https://wiki.php.net/rfc/propertygetsetsyntax-v1.2#voting Thanks, -Clint Voting has been closed, proposal declined. 34 to 22. -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] ZTS - why are you using it?
-Original Message- From: Pierre Joye [mailto:pierre@gmail.com] Sent: Wednesday, January 30, 2013 8:10 AM To: Stas Malyshev Cc: Zeev Suraski; PHP internals Subject: Re: [PHP-DEV] ZTS - why are you using it? On Wed, Jan 30, 2013 at 2:15 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Python, for example, is thread safe by default. Extensions developers Doesn't Python have global engine lock? Right, but they do not give up thread safety. See Thread State and the Global Interpreter Lock in: http://docs.python.org/2/c-api/init.html Pierre, As Stas pointed out a global lock has very little to do with the topic of discussion here. What PHP is trying to do is *much* more ambitious, so ambitious that at least I concluded it's not an achievable goal. This has nothing to do with laziness, much like deprecating safe_mode wasn't about laziness - it was about facing reality. The Python approach is exceptionally lazy (in software development that's often a Good Thing), and can be implemented very quickly if we wanted to. It wouldn't help you one bit with your use cases, though. The TS model in php should be redesigned in the next major version, instead of simply giving it up. I don't mind that we redesign TS for the next version, with two key issues: 1. I'm not sure that relying on TLS (beyond what we already do on TSRM today) is feasible. That was the naďve approach that I first tried back in 1999 and ended up ditching since it wasn't suitable. The two main ones are: [a] limited TLS space (we have *lots* of globals) [b] Inability to access globals from another image (e.g.., you won't be able to access sapi_globals which belong to php5.dll from mysqli.dll). Point [b] is mentioned in the RFC that you referred to. Point [a] might have been solved over the course of the last decade. TSRM wasn't designed for fun, it was there to solve real problems that TLS did not solve. 2. I think it's not very good use of our time. Based on what I heard in this thread, I would give up right here and now on the goal of having PHP run in-process in multithreaded web server. The pros pale in comparison to the cons. I would *not* remove ZTS - this was never the point of this thread - but I would recalibrate people's expectations about it. It sounds as if it could be useful for advanced 'I know what I'm doing' use cases like long-running threaded processes, and may be useful for the future if we ever want to support threads within a single request - but that's about it. Based on the feedback on this thread, I think we should instruct users that using thread-safe versions of PHP is slower, and that actually putting thread-safe PHP inside a multithreaded server is not a very reliable solution. We should recommend FastCGI/fpm instead. We should do that tomorrow morning (figuratively speaking). Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] moving some READMEs to the wiki
On 1/29/2013 6:54 PM, Stas Malyshev wrote: Hi! I think having stuff on the wiki is nice, but for things related to the code - e.g., APIs, builds descriptions, etc. - they should stay in the code. They are easier to find there and easier to keep up-to-date, and also ensure they have the content relevant to specific version. We could have a wiki mirror - if somebody volunteers to maintain the wiki structure and keep it up-to-date. Do we have such person? I think first we need to create a place - wiki or manual, but somewhere - where this content is created and kept up-to-date, and properly versioned when relevant. When it happens, we can start replacing some of the docs with the links to this content. I agree that the repo should be the source from which the wiki pages flow, but making them more readily accessible to people not even aware of their existence (never downloaded a tarball) would really improve visibility for non-core. I know Ferenc already said there is something like it now, perhaps it can be updated to bring these files into the wiki in an automated fashion? If that's something that is needed/desired, I could head that up as a step in the direction of building the number of core devs. Alternatively as mentioned just a moment ago, the Wiki format is plainly readable in text form so if we just switched to writing these repo files in a more wiki-friendly format, they can simply be mirrored into the wiki to make them more widely consumable without taking them out of the repo. -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] SSL renegotiation DoS attack mitigation
PHP is currently susceptible to the DoS attack described here: http://www.ietf.org/mail-archive/web/tls/current/msg07553.html Obviously this is a fairly narrow scenario, it only comes into play when PHP is acting as a socket server providing secure connectivity, it is not the responsibility of PHP to counter low-level attacks like this when it is running behind a web server. This is not really a PHP issue as such, more a problem with OpenSSL, which currently does not allow you to disable renegotiation - the feature was implemented in 0.9.8l and subsequently dropped. However I believe it should still be possible to mitigate this attack in PHP, through the use of SSL_CTX_set_info_callback(): http://www.openssl.org/docs/ssl/SSL_CTX_set_info_callback.html It should be possible to capture the SSL_CB_HANDSHAKE_START event and utilise it to implement a rate limiting for renegotiations. If I am reading the not-100%-clear documentation correctly, the callback will be fired with this reason code when a renegotiation occurs, so it should be possible (?) to use this to implement an interval threshold, above which the connection will be dropped. It would also be good to have this controllable via a stream context option, and maybe to provide the possibility for a user-land callback as well, since the rate limiting would mean the attack could still theoretically be performed via multiple connections. I am unable to provide a patch for this straight off the bat, as I do not know the PHP source well enough and my C-fu may not be good enough, but if it is something the community might be interested in/would find acceptable my colleagues and/or I can look at providing an implementation. Please note (to avoid confusion) that this does not pertain to the MITM attack described here: http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html This attack is not possible as long as PHP was compiled against OpenSSL 0.9.8m or later. Best Regards Chris Wright -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About PTY
On 30/01/13 11:58, Ferenc Kovacs wrote: On Wed, Jan 30, 2013 at 11:51 AM, Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net wrote: Hi, I wonder if PHP supports PTY? I see old codes (from 2004 to 2010) using proc_open with $descriptors = [[0 = 'pty']] for example. When I try, I have an error because PTY seems to not be supported. ./configure does not propose me to --enable-pty as I have seen in some related posts. Hi, Hi, based on http://lxr.php.net/xref/PHP_TRUNK/ext/standard/proc_open.c#653 and http://lxr.php.net/xref/PHP_TRUNK/ext/standard/proc_open.c#64 (notice the 0 ) I would say it isn't supported anymore. Yup, I have seen this condition after sending the email. wez turned that off 9 years ago: https://github.com/php/php-src/commit/bd818c0118ba406d82f901d4f97a134727440df4 But why? Are arguments always valid today? Thanks. -- Ivan Enderlin Developer of Hoa http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About PTY
On Wed, Jan 30, 2013 at 12:45 PM, Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net wrote: On 30/01/13 11:58, Ferenc Kovacs wrote: On Wed, Jan 30, 2013 at 11:51 AM, Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net wrote: Hi, I wonder if PHP supports PTY? I see old codes (from 2004 to 2010) using proc_open with $descriptors = [[0 = 'pty']] for example. When I try, I have an error because PTY seems to not be supported. ./configure does not propose me to --enable-pty as I have seen in some related posts. Hi, Hi, based on http://lxr.php.net/xref/PHP_**TRUNK/ext/standard/proc_open.** c#653 http://lxr.php.net/xref/PHP_TRUNK/ext/standard/proc_open.c#653and http://lxr.php.net/xref/PHP_**TRUNK/ext/standard/proc_open.**c#64http://lxr.php.net/xref/PHP_TRUNK/ext/standard/proc_open.c#64 (notice the 0 ) I would say it isn't supported anymore. Yup, I have seen this condition after sending the email. wez turned that off 9 years ago: https://github.com/php/php-**src/commit/**bd818c0118ba406d82f901d4f97a13* *4727440df4https://github.com/php/php-src/commit/bd818c0118ba406d82f901d4f97a134727440df4 But why? Are arguments always valid today? Thanks. from the previous commits it seems that we had some kind of proc_open build issue and didn't managed to solve it without removing that: http://git.php.net/?p=php-src.git;a=history;f=ext/standard/proc_open.c;h=2041d3481ff389e9b2f17d3073176bfdffb0494a;hb=bd818c0118ba406d82f901d4f97a134727440df4 -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] About PTY
On Wed, Jan 30, 2013 at 12:53 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Wed, Jan 30, 2013 at 12:45 PM, Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net wrote: On 30/01/13 11:58, Ferenc Kovacs wrote: On Wed, Jan 30, 2013 at 11:51 AM, Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net wrote: Hi, I wonder if PHP supports PTY? I see old codes (from 2004 to 2010) using proc_open with $descriptors = [[0 = 'pty']] for example. When I try, I have an error because PTY seems to not be supported. ./configure does not propose me to --enable-pty as I have seen in some related posts. Hi, Hi, based on http://lxr.php.net/xref/PHP_**TRUNK/ext/standard/proc_open.** c#653 http://lxr.php.net/xref/PHP_TRUNK/ext/standard/proc_open.c#653and http://lxr.php.net/xref/PHP_**TRUNK/ext/standard/proc_open.**c#64http://lxr.php.net/xref/PHP_TRUNK/ext/standard/proc_open.c#64 (notice the 0 ) I would say it isn't supported anymore. Yup, I have seen this condition after sending the email. wez turned that off 9 years ago: https://github.com/php/php-**src/commit/**bd818c0118ba406d82f901d4f97a13 **4727440df4https://github.com/php/php-src/commit/bd818c0118ba406d82f901d4f97a134727440df4 But why? Are arguments always valid today? Thanks. from the previous commits it seems that we had some kind of proc_open build issue and didn't managed to solve it without removing that: http://git.php.net/?p=php-src.git;a=history;f=ext/standard/proc_open.c;h=2041d3481ff389e9b2f17d3073176bfdffb0494a;hb=bd818c0118ba406d82f901d4f97a134727440df4 -- Ferenc Kovács @Tyr43l - http://tyrael.hu and for the record, it seems that the whole feature lived less than a month and a half, so it isn't something that we properly tested or announced. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] ZTS - why are you using it?
On 29/01/2013 09:03, Zeev Suraski wrote: I’m creating a new one, based on the apparent level of interest in ZTS. This isn’t an RFC to remove ZTS by any stretch, but I **am** a bit confused about why people are still using ZTS. Personally because runkit sandbox requires it, amongst other extensions. Haven't had a chance to play with it yet but the new pthreads extension requires it which I'm probably going to be using extensively in future too. Why does it need to be enabled for most people? It probably doesn't, but there are many third part extensions that can't function without it with no obvious workarounds that would cease to exist if it hypothetically disappeared. This for me, and I suppose many others would be a fairly major problem. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] send/recvmsg() wrappers in ext/socket
On Tue, 22 Jan 2013 18:23:59 +0100, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: https://wiki.php.net/rfc/sendrecvmsg The module ext/sockets, a wrapper around the sockets API, does not include support to recvmsg() and sendmsg(). This RFC addresses this shortcoming by support introducing limited (only a few types of messages are supported) support for these functions. Since no one has commented and the feature freeze for 5.5 is getting near, I'm just going to assume lazy consensus and merge this in once I get it to build on Windows. So if you do have any objection (procedural or substantial), please raise it soon. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ZTS - why are you using it?
Hi Guys, As a heavy user of ZTS in multi threaded C/C++ applications, here are my $0.02. Removing ZTS would be a bad idea for all those custom multi-threaded applications out there that allow some form of internal/embedded PHP scripting. These applications are not web-servers but do make use of threads for reasons of their own. Building a FastCGI set-up would be out of the question if these apps are deployed customer / client side and need concurrent PHP script runs. Based on the feedback on this thread, I think we should instruct users that using thread-safe versions of PHP is slower, and that actually putting thread-safe PHP inside a multithreaded server is not a very reliable solution. We should recommend FastCGI/fpm instead. We should do that tomorrow morning (figuratively speaking). Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php This makes a lot of sense, I see where FastCGI/fpm is the best solution for the majority of users of PHP which deploy large scale web applications. The tone in this conversation looked like ZTS had no place in the PHP future. I think it does, but maybe not for the regular web server / web application use case. For custom applications with embedded PHP, I see it making more and more sense as a lot of native applications need to interface with web services and often SDK's for these services are either not available or tedious to use for native application development. Being able to use the PHP SDK's and quickly build conduits between custom apps and services using PHP is very beneficial. Developers of these kind of apps are well aware of the potential pitfalls in using threads and potential non TS libraries as long as documentation is clear about it. My biggest worry is when we signal that ZTS is a relic or not important enough to support in extensions we end up with developers building extensions not trying to be ZTS compatible even if they could be made thread safe easily. For the majority of extensions it's a simple question of adding the TSRM macros. If the underlying library doesn't support it or it would impact performance too much, I would at least want to know that the extension is not thread safe so I can leave it aside and come up with another solution. Bas van Beek -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] ZTS - why are you using it?
-Original Message- From: Bas van Beek [mailto:b...@tobin.nl] Sent: Wednesday, January 30, 2013 2:29 PM To: Zeev Suraski Cc: Pierre Joye; Stas Malyshev; PHP internals Subject: Re: [PHP-DEV] ZTS - why are you using it? Hi Guys, As a heavy user of ZTS in multi threaded C/C++ applications, here are my $0.02. Removing ZTS would be a bad idea for all those custom multi-threaded applications out there that allow some form of internal/embedded PHP scripting. These applications are not web-servers but do make use of threads for reasons of their own. Building a FastCGI set-up would be out of the question if these apps are deployed customer / client side and need concurrent PHP script runs. Based on the feedback on this thread, I think we should instruct users that using thread-safe versions of PHP is slower, and that actually putting thread-safe PHP inside a multithreaded server is not a very reliable solution. We should recommend FastCGI/fpm instead. We should do that tomorrow morning (figuratively speaking). In case I wasn't sufficiently clear, I'm talking about putting PHP inside a *multithreaded web server*, not being a good idea. The use case you specify is exactly the use case for keeping ZTS support in the code... Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] send/recvmsg() wrappers in ext/socket
Seeing as it doesn't break BC, and could be quite useful I don't see why you shouldn't merge it. On Wed, Jan 30, 2013 at 8:25 AM, Gustavo Lopes glo...@nebm.ist.utl.ptwrote: On Tue, 22 Jan 2013 18:23:59 +0100, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: https://wiki.php.net/rfc/**sendrecvmsghttps://wiki.php.net/rfc/sendrecvmsg The module ext/sockets, a wrapper around the sockets API, does not include support to recvmsg() and sendmsg(). This RFC addresses this shortcoming by support introducing limited (only a few types of messages are supported) support for these functions. Since no one has commented and the feature freeze for 5.5 is getting near, I'm just going to assume lazy consensus and merge this in once I get it to build on Windows. So if you do have any objection (procedural or substantial), please raise it soon. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- *Brandon Wamboldt* Software Engineer Resume/CV http://brandonwamboldt.com/cv/ - Personal Site/Bloghttp://brandonwamboldt.ca/ - LinkedIn http://ca.linkedin.com/in/brandonwamboldt - StackOverflow Careers Profile http://careers.stackoverflow.com/brandonwamboldt - GitHub Profile https://github.com/brandonwamboldt
Re: [PHP-DEV] ZTS - why are you using it?
Op 30 jan. 2013, om 13:42 heeft Zeev Suraski het volgende geschreven: -Original Message- From: Bas van Beek [mailto:b...@tobin.nl] Sent: Wednesday, January 30, 2013 2:29 PM To: Zeev Suraski Cc: Pierre Joye; Stas Malyshev; PHP internals Subject: Re: [PHP-DEV] ZTS - why are you using it? Hi Guys, As a heavy user of ZTS in multi threaded C/C++ applications, here are my $0.02. Removing ZTS would be a bad idea for all those custom multi-threaded applications out there that allow some form of internal/embedded PHP scripting. These applications are not web-servers but do make use of threads for reasons of their own. Building a FastCGI set-up would be out of the question if these apps are deployed customer / client side and need concurrent PHP script runs. Based on the feedback on this thread, I think we should instruct users that using thread-safe versions of PHP is slower, and that actually putting thread-safe PHP inside a multithreaded server is not a very reliable solution. We should recommend FastCGI/fpm instead. We should do that tomorrow morning (figuratively speaking). In case I wasn't sufficiently clear, I'm talking about putting PHP inside a *multithreaded web server*, not being a good idea. The use case you specify is exactly the use case for keeping ZTS support in the code... Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Yes I did get that and my response to your post was not meant as an argument against those points but more as an addition. I just wanted to re-enforce that ZTS has it's purpose and we should be careful about which signals we give to the PHP user-land and extension developer community as most of the previous posts to this thread seemed to discard usefulness of ZTS all together as if the only important use case is running PHP code on a web server. PHP is so much more than that and I do not want to see PHP developers exclude or forget about these other use cases because prominent people in the PHP community make blunt statements as the above topic implies. Bas van Beek -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ZTS - why are you using it?
On Wed, Jan 30, 2013 at 1:42 PM, Zeev Suraski z...@zend.com wrote: In case I wasn't sufficiently clear, I'm talking about putting PHP inside a *multithreaded web server*, not being a good idea. It makes no sense where FPM is supported, or little sense. The use case you specify is exactly the use case for keeping ZTS support in the code... This use case fits in both new SAPIs I was talking about earlier, as the way they work will be pretty much the same. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
Hi 2013/1/30 Stas Malyshev smalys...@sugarcrm.com: How it's more outside product than any of the other extensions we brought to the core? Because it was not developed at php.net for example? How many extensions thats in the core today was not developed somewhere at php.net, or was either in PECL first? What I'm saying is that I think it should go to PECL first before getting adapted into the core, no matter who or where it was developed from if it was not developed here, yes I realize I make it sound like an alien artifact as Zeev said. What if the guys at XCache asked for it to be added to the main distribution, I'm pretty sure that most would say let it to go PECL or compare it with APC and have a race there, but the fact that it is (with all respect) guys who worked heavily on the Engine seems to blind some people, which is what I'm against. -- 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] Integrating Zend Optimizer+ into the PHP distribution
This is the kind of info the RFC (and then user doc) should have. I updated the RFC with two extra sections - 'what's an opcode cache', and 'interaction with other plugins'. https://wiki.php.net/rfc/optimizerplus Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
Hi Zeev, Specifically would it continue to work with the Zend Guard decoder (as it does now)? Thanks, John. -Original Message- From: Zeev Suraski [mailto:z...@zend.com] Sent: 30 January 2013 14:48 To: Christopher Jones Cc: internals@lists.php.net Subject: RE: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution This is the kind of info the RFC (and then user doc) should have. I updated the RFC with two extra sections - 'what's an opcode cache', and 'interaction with other plugins'. https://wiki.php.net/rfc/optimizerplus Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] echo new SplFileObject(__FILE__);
- Ursprüngliche Message - Von: Stas Malyshev smalys...@sugarcrm.com Gesendet: 0:00 Mittwoch, 30.Januar 2013 Betreff: Re: [PHP-DEV] echo new SplFileObject(__FILE__); __toString is mapped to current() for SplFileObject: http://www.php.net/manual/en/splfileobject.current.php it's not documented for some reason, I think it makes sense to file a docs bug on that. Thanks for your answer. I know that there is code in there that does this and I also got into the know that it is not properly documented. I just write this to clarify that I'm more interested in the why it has been coded that way. It does not make much *sense* to me and I want to learn more. Also I don't mean this explicit technically. I could blame the version control, pick the authors name and email that person; however some time has passed and more users are using it not only the original author so I ask in internals first. Just for clarification. -- hakre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
On 30 בינו 2013, at 16:57, John Carter jcar...@identitynetworks.com wrote: Hi Zeev, Specifically would it continue to work with the Zend Guard decoder (as it does now)? Our (Zend's) goal would be yes. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] echo new SplFileObject(__FILE__);
To be honest, it looks like __toString() was just added in there for the sake of it without any real thought as to what casting an entier SplFileObject to a string. This to me implies the entire object( i.e: the entire file ) should be returned as a string rather than aliasing it to a method because why would you cast something to a string if you can call -current() anyway. Since it's been baked into the object for some time now it can't even be changed now. I'd try to avoid this casting magic and stick with -current() if you actually mean it. Thanks, Paul Dragoonis. On Wed, Jan 30, 2013 at 3:44 PM, hakre hanskren...@yahoo.de wrote: - Ursprüngliche Message - Von: Stas Malyshev smalys...@sugarcrm.com Gesendet: 0:00 Mittwoch, 30.Januar 2013 Betreff: Re: [PHP-DEV] echo new SplFileObject(__FILE__); __toString is mapped to current() for SplFileObject: http://www.php.net/manual/en/splfileobject.current.php it's not documented for some reason, I think it makes sense to file a docs bug on that. Thanks for your answer. I know that there is code in there that does this and I also got into the know that it is not properly documented. I just write this to clarify that I'm more interested in the why it has been coded that way. It does not make much *sense* to me and I want to learn more. Also I don't mean this explicit technically. I could blame the version control, pick the authors name and email that person; however some time has passed and more users are using it not only the original author so I ask in internals first. Just for clarification. -- hakre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] echo new SplFileObject(__FILE__);
On Wed, Jan 30, 2013 at 4:44 PM, hakre hanskren...@yahoo.de wrote: - Ursprüngliche Message - Von: Stas Malyshev smalys...@sugarcrm.com Gesendet: 0:00 Mittwoch, 30.Januar 2013 Betreff: Re: [PHP-DEV] echo new SplFileObject(__FILE__); __toString is mapped to current() for SplFileObject: http://www.php.net/manual/en/splfileobject.current.php it's not documented for some reason, I think it makes sense to file a docs bug on that. Thanks for your answer. I know that there is code in there that does this and I also got into the know that it is not properly documented. I just write this to clarify that I'm more interested in the why it has been coded that way. It does not make much *sense* to me and I want to learn more. Also I don't mean this explicit technically. I could blame the version control, pick the authors name and email that person; however some time has passed and more users are using it not only the original author so I ask in internals first. Just for clarification. I would guess the idea was that SplFileObject already implements the Iterator interfaces and iterating the object would give you the lines of the file, so echo $object should echo the current line. But this isn't that strong of an argument, and I think that following what SplFileInfo does would be more sensible (echoing the filename), but I'm not sure change would worth breaking BC for. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
WG: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
- Weitergeleitete Message - Von: hakre hanskren...@yahoo.de An: Zeev Suraski z...@zend.com CC: Gesendet: 17:09 Mittwoch, 30.Januar 2013 Betreff: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution - Ursprüngliche Message - Von: Zeev Suraski z...@zend.com An: internals@lists.php.net CC: Gesendet: 9:03 Dienstag, 29.Januar 2013 Betreff: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution All, Following the discussion at the end of last week, I prepared a draft RFC for the inclusion of Optimizer+ in PHP. I have some questions: * In that RFC you write: the integration won’t happen before late 2014. [if it's not bundled with PHP 5.5] Can you please outline why? Especially does it mean you stop contributing to the PECL development if you don't get this bundled with PHP 5.5? Also can you please outline why you put obviously so much focus in bundling this to PHP 5.5? Or is my impression wrong? * With full respect and the best intentions: Are you able and if yes, can you share about the motivation why you decided (quite surprisingly) to contribute at this place in time? As you wrote in the past many PHP core contributors also worked on that component while it's well known that PHP is not really useable as platform without an opcode cache in an attractive field. You also wrote in an earlier email that you got out of sync with your userbase. Under these circumstances, the impression could be that it took a little bit too long until this decision was done and I would like to see this impression clarified because there are many loose ends. * Is this surprising and welcomed release related in any way to the Openstack Initiative? * Which benefits does Zend Inc. see in contributing the Opcode cache? * Last but not least, not related to the opcode cache alone, but related because you want to bundle it with core: If some day the PHP group decides to choose a similar software license, but different in the sense that it is more compatible with existing FLOSS licensing, would you have a problem to re-license as well, e.g. under MIT or Apache 2.0 for that part? Thank you for taking your time, I know I ask about a lot, but it would be great if you give some insights that are not covered by the RFC but could play a role to make up ones mind about this contribution. Thank you. -- hakre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] echo new SplFileObject(__FILE__);
Von: Paul Dragoonis dragoo...@gmail.com Gesendet: 16:54 Mittwoch, 30.Januar 2013 To be honest, it looks like __toString() was just added in there for the sake of it without any real thought as to what casting an entier SplFileObject to a string. This to me implies the entire object( i.e: the entire file ) should be returned as a string rather than aliasing it to a method because why would you cast something to a string if you can call -current() anyway. Since it's been baked into the object for some time now it can't even be changed now. Would this mean that changing it in PHP 5.5 (or 5.6) would not be an option because of the rules of backwards compatibility? I'd try to avoid this casting magic and stick with -current() if you actually mean it. So do I. I mean, I often foreach anyway. -- hakre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
* In that RFC you write: the integration won’t happen before late 2014. [if it's not bundled with PHP 5.5] Can you please outline why? Based on an 18 month release cycle, and assuming we release 5.5.0 in mid 2013, 5.6.0 will come out late 2014. Especially does it mean you stop contributing to the PECL development if you don't get this bundled with PHP 5.5? No. If you take a closer look at the options, the 'No' option reads 'Don’t integrate Optimizer+ to PHP, provide it as an optional component in PECL only'. We're going to publish the code as soon as we can, I hope no later than next week, and it'll be before we have the results of the vote. By 'integration' I refer to going beyond just including it in PECL, but including it in core. Also can you please outline why you put obviously so much focus in bundling this to PHP 5.5? Or is my impression wrong? Optimizer+ has been a free (closed source) component since 2008. We've been talking about open sourcing it numerous times over the years but it was never prioritized high enough. With the discussion last week about integrating an opcode cache into PHP's core, the challenges of using APC for that purpose on a short timeline, and the fact Optimizer+ is a significantly faster implementation than APC - I thought that this could be a good opportunity to commit ourselves (Zend) into doing this. Otherwise it would have probably never happened. To me, waiting for a couple of months to get a huge performance gain out-of-the-box is a no brainer. In fact, it might be a way to convince a lot of people that migrating is worth it. * With full respect and the best intentions: Are you able and if yes, can you share about the motivation why you decided (quite surprisingly) to contribute at this place in time? See above answer. You also wrote in an earlier email that you got out of sync with your userbase. I did not. Perhaps you read it that way :) Pierre said something along the lines of 'some people here being disconnected from our userbase'. I agreed with him, but obviously, I wasn't talking about myself. Under these circumstances, the impression could be that it took a little bit too long until this decision was done and I would like to see this impression clarified because there are many loose ends. Please bring up any loose ends you're spotting and I'll try to address them as best I can. * Is this surprising and welcomed release related in any way to the Openstack Initiative? Not at all. * Which benefits does Zend Inc. see in contributing the Opcode cache? Simply put, this could benefit PHP greatly without negatively affecting our business in any way. * Last but not least, not related to the opcode cache alone, but related because you want to bundle it with core: If some day the PHP group decides to choose a similar software license, but different in the sense that it is more compatible with existing FLOSS licensing, would you have a problem to re-license as well, e.g. under MIT or Apache 2.0 for that part? The plan is to contribute the source code to the PHP project. It'll be under the same license as PHP and subject to any changes in the PHP licensing scheme that we'll agree on. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
On Wed, Jan 30, 2013 at 5:47 PM, Zeev Suraski z...@zend.com wrote: * In that RFC you write: the integration won’t happen before late 2014. [if it's not bundled with PHP 5.5] Can you please outline why? Based on an 18 month release cycle, and assuming we release 5.5.0 in mid 2013, 5.6.0 will come out late 2014. it is more a 12-14 months actually. And it should be so. -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] echo new SplFileObject(__FILE__);
Hi! But this isn't that strong of an argument, and I think that following what SplFileInfo does would be more sensible (echoing the filename), but I'm not sure change would worth breaking BC for. I don't see why it would be more sensible. It's different objects that do different things - Info represents file name, more or less, while Object represents file contents. I see no reason why it would only make sense for Object to return filename, or why we should fix something that is not broken. -- 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] [RFC] Integrating Zend Optimizer+ into the PHP distribution
-Original Message- From: Pierre Joye [mailto:pierre@gmail.com] Sent: Wednesday, January 30, 2013 7:22 PM To: Zeev Suraski Cc: hakre; PHP internals Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution On Wed, Jan 30, 2013 at 5:47 PM, Zeev Suraski z...@zend.com wrote: * In that RFC you write: the integration won't happen before late 2014. [if it's not bundled with PHP 5.5] Can you please outline why? Based on an 18 month release cycle, and assuming we release 5.5.0 in mid 2013, 5.6.0 will come out late 2014. it is more a 12-14 months actually. And it should be so. FWIW I think that's way too rapid (as I shared with you back in the day), but that's a topic for a different discussion. We have enough on our hands as it is :) Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
Hi! Because it was not developed at php.net for example? How many I'm not sure what is the meaning here. Nothing is developed at php.net, strictly speaking. php.net doesn't have its own development team that works exclusively for php.net, it just gets code contributions from volunteers. And many people working right now on PHP have their salaries paid by major companies, like IBM, Microsoft, Oracle, Facebook and so on. Some of them are paid specifically for doing PHP-related stuff, AFAIK. We had a number of extensions which development was initiated and/or sponsored by various companies. Could you explain what developed at php.net really means? If I develop some extension on my laptop and then commit it to git - is is developed at php.net or not? extensions thats in the core today was not developed somewhere at php.net, or was either in PECL first? What I'm saying is that I think it should go to PECL first before getting adapted into the core, no matter who or where it was developed from if it was not developed here, yes I realize I make it sound like an alien artifact as Zeev said. If the problem is that it wasn't in PECL - the RFC says As the code becomes available, put it in PECL.. Once that happens, we can discuss moving it to core - as an extension - should be in 5.5 or later. PECL is not going away and is the first step anyway. It seems like what you're saying is that it should be in PECL at least for a year before it can be merged (please correct me if I'm wrong here). Now, I can see how it could be for an extension whose usage and stability is uncertain - we don't know yet if a parser for foobar protocol is needed or if it actually works, so let's put it in PECL and wait and see. However, here we know it (bytecode caching) is needed and this extension has been worked on for many years. Still, if you have concerns about it - it will be placed in PECL, you could see it and then make your judgement about schedule and such. -- 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] echo new SplFileObject(__FILE__);
2013.01.30. 19:16, Stas Malyshev smalys...@sugarcrm.com ezt írta: Hi! But this isn't that strong of an argument, and I think that following what SplFileInfo does would be more sensible (echoing the filename), but I'm not sure change would worth breaking BC for. I don't see why it would be more sensible. It's different objects that do different things - Info represents file name, more or less, while Object represents file contents. I see no reason why it would only make sense for Object to return filename, or why we should fix something that is not broken. imo the toString should return something which represents the object and the filename satisfy that better than a random line from the file. but I agree that this isn't a real concern and doesn't need fixing. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227
Re: [PHP-DEV] echo new SplFileObject(__FILE__);
I also agree that we don't need to fix this, nor break BC. It is confusing as hell but it's there now and changing it would be more disruptive. Is there a desire from anyone to gracefully throw E_DEPRECATED in a future version of PHP 5.x when someone tries to __toString() the SplFileObject but only get back a single line ? That's the only plan forward I can see feasible if we decided to do anything, otherwise we should move on. On Wed, Jan 30, 2013 at 6:44 PM, Ferenc Kovacs tyr...@gmail.com wrote: 2013.01.30. 19:16, Stas Malyshev smalys...@sugarcrm.com ezt írta: Hi! But this isn't that strong of an argument, and I think that following what SplFileInfo does would be more sensible (echoing the filename), but I'm not sure change would worth breaking BC for. I don't see why it would be more sensible. It's different objects that do different things - Info represents file name, more or less, while Object represents file contents. I see no reason why it would only make sense for Object to return filename, or why we should fix something that is not broken. imo the toString should return something which represents the object and the filename satisfy that better than a random line from the file. but I agree that this isn't a real concern and doesn't need fixing. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227
Re: [PHP-DEV] echo new SplFileObject(__FILE__);
On 30 January 2013 18:48, Paul Dragoonis dragoo...@gmail.com wrote: Is there a desire from anyone to gracefully throw E_DEPRECATED in a future version of PHP 5.x when someone tries to __toString() the SplFileObject but only get back a single line ? Absolutely not. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] New SSL stream context option to prevent CRIME attack vector
Hi, we have an open PR for a new SSL stream context option to prevent the CRIME attack vendor. Anybody with more familiar knowledge of SSL should have a look: https://github.com/php/php-src/pull/269 cu, Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context (example of real usage that will break)
Rebuttal inline... - and better solution at end...
On Tuesday, January 29, 2013 01:46 PM, Stas Malyshev wrote:
Hi!
I've used this in other places, it's basically lightweight traits, and
has always been perfectly valid code. There does not seem to be a clear
justification for deprecating it other than, It's not the way 'some'
people like code to work...
Well, I think the reason is that this code is unsafe and goes against
the principles of OO. I understand that there's a tendency to use OO as
a neat way to namespace global functions and autoload them, but that's
not how it is supposed to work.
Actually even If I used Trait's here, the code would be no safer, this
is kind of the absurdity of traits and this E_STRICT error, since PHP is
not a compiled language, the engine can not really determine if
accessing $this inside the trait method is really compatible scope.
Unless I'm wrong I suspect there are no checks in traits to determine
if the method tries to call methods, or write properties that are not
defined in the trait until runtime, when it explodes..
It's only suggested that it might be compatible by adding to the class.
This is why the E_STRICT warning is absurd in the first place, just
because the writer hints that $this is compatible in traits does not
mean it really is.. It is no better that the previous way of doing this.
The fact that this use of PHP is documented in the manual as a feature
www.php.net/manual/en/language.oop5.basic.php
And mentions that it will elicit a E_STRICT error - does not indicate
that it would be DEPRECATED, I'm assuming that has been documented for
years, and only recently (a year or two) has the E_STRICT comment been
added.
There is also no real Justification for the E_STRICT message = see
suggestion at end..
If addPreserveText() uses anything from Footer, it should not be called
from TextRun, but if it does not, it should be in Section.
No, if it was in Section, all the child classes would have to override
it and throw errors. That results in quite a bit of pointless
boilerplate code to solve a problem that has just been created by this
change (and really the original E_STRICT one). If the code path results
in a call to addPreserveText in the other classes, it's a pretty serious
error, and we need to catch that quick...
I certainly
disagree that the code that calls method of Footer from TextRun is easy
to follow -
Easy to follow? the code reads
.Section_Footer::addPreserveText()
That says' I'm going to call addPreserveText in section_footer, that's
about the most obvious bit of code I've ever seen
I'd be very surprised seeing such code and would
immediately think it's some kind of bad copy-paste from one class to
another. I understand that this hack works for you - but language
usually enforce some rules of what you can and can not do, according to
some guiding principles. Having this hack goes again those principles.
I'm not sure what these principles are sometimes, they seem to say we
need to implement features from compiled languages, and yet we can not
do compile time checks as we are a dynamic language. So we are going to
pretend that stuff works because we have change the syntax a bit.
As far as I know, no OO languages allow to do such things.
I did a testable version in javascript the other day. - it's similar to
this..
a = { function A() { console.log(this.value); }};
b = { function B() { a.A.call(this); }};
c = new b();
c.B();
Javascript uses .call() to modify the scope on the recieving end. I't
not that different to PHP currently, however PHP has been slightly
better as it does not need to send the scope..
It's not used alot in this way, but it handy for a duck patching methods
onto classes. - normally you would just do b.A = a.B
I note that we have people here constantly criticizing us for not
changing the names of all functions in order to satisfy their esthetic
sense, but once we change something that obviously for nearly everybody
(see vote) shouldn't even be there and never was intended to work this
way - we get criticized again for breaking stuff :)
An almost secret vote, that as I mentioned before, this was unfortunate,
that nobody spotted this before, There was objections when it was first
proposed, but that was not really mentioned in the rfc, and the vote was
done in 7 days with one message mention the start of the vote.
At least I managed to catch this one before it get's to a release.
is_a ???
I've ignored this problem for a while, I suspect this is the last of the
E_STRICT absurd uses that is stopping me from turning it on. In this
particular case it's pedantic, and goes against the idea of getting shit
done.
Why not make that E_STRICT actually useful, and change it so it only
occurs if the $this of the calling scope and the function do not share
the same top level parent.
That would make this method of doing Multiple Inheritance at small bit
more
Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context (example of real usage that will break)
Hi! I did a testable version in javascript the other day. - it's similar to this.. Javascript is not really an OO language. It has objects, but it doesn't really follow or enforce any of OO paradigms. It's prototype-based, so things work differently there. An almost secret vote, that as I mentioned before, this was unfortunate, that nobody spotted this before, There was objections when it was first There was not any secret vote. It was announced on the list, just as any other votes are. I understand one can miss stuff, but there was nothing secret, it was standard process. proposed, but that was not really mentioned in the rfc, and the vote was done in 7 days with one message mention the start of the vote. How many messages are necessary? Are we supposed to spam the list for weeks in hope people would actually read it? I think one is perfectly enough. Why not make that E_STRICT actually useful, and change it so it only occurs if the $this of the calling scope and the function do not share the same top level parent. What common top level parent has to do with it? If you call common parent function, you don't need to call into wrong scope - you can call it from the same scope. It's when you want to call method that is not in your scope but pretend that it is - then you need wrong scope call. And it's not supposed to work this way - you're not supposed call methods on objects that don't have this method in their class. -- 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] [VOTE] Deprecate and remove calls from incompatible context (example of real usage that will break)
Top posting as the discussion was going a bit off topic. (Yes there was
a vote, but the rfc could do with some refinements.)
This is an illustration of the proposed change to the RFC, and the
absurdity of how trait's allow incompatible scopes, and give no similar
warning
Example1 - illustrates the problem that the traits hides the problems
that E_DEPRECATED/E_STRICT is trying to show.
Obviously in a compiled language this would be picked up, but we can not
do it in a scripted language.
trait test {
function a() {
// b does not exist in testb - so in theory $this is in an
incompatible scope.
// however no warning is raised as it's in a trait. - it just
says Fatal error
$this-b();
}
}
class testb {
use test;
function testb() {
$this-a();
}
}
new testb();
Example2 - what should work without warnings.
class base { }
class testa extends base {
var $v = 'testa';
function a() {
// usage of $this elicits E_STRICT
// however, testa and testb share the same parent and may be
reasonably compatible.
// suggested fix - do not emit warning if $this (testb) and
(testa) both have the same top level parent or interface...
// in all other scenarios - emit E_DEPRECATED (eg. if $this ==
null, or some unrelated class)
echo $this-v;
}
}
class testb extends base {
var $v = 'testb';
function testb() {
testa::a();
}
}
new testb();
Regards
Alan
On Thursday, January 31, 2013 08:00 AM, Stas Malyshev wrote:
Hi!
I did a testable version in javascript the other day. - it's similar to
this..
Javascript is not really an OO language. It has objects, but it doesn't
really follow or enforce any of OO paradigms. It's prototype-based, so
things work differently there.
An almost secret vote, that as I mentioned before, this was unfortunate,
that nobody spotted this before, There was objections when it was first
There was not any secret vote. It was announced on the list, just as
any other votes are. I understand one can miss stuff, but there was
nothing secret, it was standard process.
proposed, but that was not really mentioned in the rfc, and the vote was
done in 7 days with one message mention the start of the vote.
How many messages are necessary? Are we supposed to spam the list for
weeks in hope people would actually read it? I think one is perfectly
enough.
Why not make that E_STRICT actually useful, and change it so it only
occurs if the $this of the calling scope and the function do not share
the same top level parent.
What common top level parent has to do with it? If you call common
parent function, you don't need to call into wrong scope - you can call
it from the same scope. It's when you want to call method that is not in
your scope but pretend that it is - then you need wrong scope call. And
it's not supposed to work this way - you're not supposed call methods on
objects that don't have this method in their class.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context (example of real usage that will break)
If addPreserveText() uses anything from Footer, it should not be called
from TextRun, but if it does not, it should be in Section.
No, if it was in Section, all the child classes would have to override
it and throw errors. That results in quite a bit of pointless
boilerplate code to solve a problem that has just been created by this
change (and really the original E_STRICT one). If the code path results
in a call to addPreserveText in the other classes, it's a pretty serious
error, and we need to catch that quick...
Not going to sound off on other subtopics in this thread, about which
my feelings are mixed, but your note here is pretty strange. I agree
with Stas and others that you are already using an antipattern, so if
a major justification is that you need to manually authorize a
subclass to call the super, you don't need to override and throw in
every possible subclass, how about something like this instead to
whitelist:
interface preservable
{
public function addPreserveText();
}
abstract class section {
public function addPreserveText()
{
if (!isset(class_implements($this)[preservable]))
throw new Exception(can't call super from disallowed
subclass);
echo ready to rumble;
}
}
class footer extends section implements preservable {}
class header extends section {}
$myfoot = new footer();
$myfoot-addPreserveText(); // ready to rumble
$myhead = new header();
$myhead-addPreserveText(); // error
-- Sandy
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Deprecate and remove calls from incompatible context
Some of us have rather large bodies of code written over 10-12 years that make significant use of calling $this from incompatible contexts (i.e. we know it's compatible, but php doesn't). Most consider such use a sin. Could there be a compromise that would allow us evildoers to continue in our evil ways without identifying and changing every use? Perhaps implements allowStaticCallsFromIncompatibleContexts or somesuch? I can imagine replacing every class ... with class ... implements ..., but identifying and changing every place we use an incompatible context will be very, very unpleasant. We can figure out the places that are hit most frequently using the logs, but that isn't necessarily a complete list. If this were a security issue, I'd understand making everyone go through the pain. The RFC indicates the rationale is helping users find bugs. It would be nice if those of us who would rather avoid a BC break than easily find those bugs could do so. Thanks for your consideration. - Todd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
