[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

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 so

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 - illustrat

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

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 oth

[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://w

Re: [PHP-DEV] echo new SplFileObject(__FILE__);

On 30 January 2013 18:48, Paul Dragoonis 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 M

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 onl

Re: [PHP-DEV] echo new SplFileObject(__FILE__);

2013.01.30. 19:16, "Stas Malyshev" 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 se

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 m

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 S

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 - In

Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution

On Wed, Jan 30, 2013 at 5:47 PM, Zeev Suraski 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 >

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 mea

Re: [PHP-DEV] echo new SplFileObject(__FILE__);

> Von: Paul Dragoonis >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

WG: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution

- Weitergeleitete Message - > Von: hakre > An: Zeev Suraski > 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 >> An: internals@lis

Re: [PHP-DEV] echo new SplFileObject(__FILE__);

On Wed, Jan 30, 2013 at 4:44 PM, hakre wrote: > > > - Ursprüngliche Message - > > > Von: Stas Malyshev > > Gesendet: 0:00 Mittwoch, 30.Januar 2013 > > Betreff: Re: [PHP-DEV] echo new SplFileObject(__FILE__); > > > > > > __toString is mapped to current() for SplFileObject: > > http://www.

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 becaus

Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution

On 30 בינו 2013, at 16:57, John Carter 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__);

- Ursprüngliche Message - > Von: Stas Malyshev > 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 documen

Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution

On 1/30/13 8:36 AM, Kalle Sommer Nielsen wrote: 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 Isn't the important thing whether it survives the RFC/voting process? If devs agree with you that time served i

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] Integrati

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, vi

Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution

Hi 2013/1/30 Stas Malyshev : > 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

Re: [PHP-DEV] ZTS - why are you using it?

On Wed, Jan 30, 2013 at 1:42 PM, Zeev Suraski 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

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 ar

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 wrote: > On Tue, 22 Jan 2013 18:23:59 +0100, Gustavo Lopes > wrote: > > https://wiki.php.net/rfc/**sendrecvmsg >

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+

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

Re: [PHP-DEV] [RFC] send/recvmsg() wrappers in ext/socket

On Tue, 22 Jan 2013 18:23:59 +0100, Gustavo Lopes 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 type

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 e

Re: [PHP-DEV] About PTY

On Wed, Jan 30, 2013 at 12:53 PM, Ferenc Kovacs 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.

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 c

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 erro

[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

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 r

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 > wrote: > > Hi!

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/

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 supp

[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. Than

Re: [PHP-DEV] ZTS - why are you using it?

On Wed, Jan 30, 2013 at 11:33 AM, Lester Caine 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?

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 sys

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.

Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context

On Wed, Jan 30, 2013 at 10:50 AM, Lester Caine wrote: > 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

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 'advi

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 l

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 t

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,