Hi,
Hi,
>
> My biggest concern about supporting friend classes is the ability to
> access non-intentional to be accessed code outside of the original class's
> knowledge. This by itself is very dangerous.
>
Just to clarify, the original class explicitly declares friends of itself.
There is no opp
Hi,
My biggest concern about supporting friend classes is the ability to access
non-intentional to be accessed code outside of the original class's
knowledge. This by itself is very dangerous.
I do see however package-private classes as a possibility (I actually have
a partially running patch for
Hi!
The topic of class / function friendship has been recently discussed and
previously covered in the past through this list as well as through feature
requests against bugs.php.net. I've recently developed an interest in the
feature after reaching for a tool that just didn't exist in a language
On Dec 7, 2015, at 18:17, Rasmus Lerdorf wrote:
>
>> On Dec 7, 2015, at 16:28, Lester Caine wrote:
>>
>> PHP7 is around 10% slower ... and given that half the time is taken
>> in database lookup, the code performance is potentially worse. So what
>> am I missing?
>
> Then you have a config pro
On Dec 7, 2015, at 16:28, Lester Caine wrote:
>
> PHP7 is around 10% slower ... and given that half the time is taken
> in database lookup, the code performance is potentially worse. So what
> am I missing?
Then you have a config problem. The first and obvious thing to check is your
opcache set
OK now have a working nginx server with both the current production
setup and PHP7 php-fpm both running the same code base ...
Just a few __construct switches from their named constructor ( still
don't see why we need to kill the named version MUCH tidier seeing the
name of the parent class ) and
sdev
Hi,
- Original Message
From: "Andrea Faulds"
Sent: Monday, December 07, 2015
Hi Matt,
Matt Wilmas wrote:
Hi Bob, all,
After this commit:
http://git.php.net/?p=php-src.git;a=commitdiff;h=509712c7d9056b4ceb50134bfeea1a1115720744
In streamsfuncs.c, line 996 has an extra comma; and li
Den 2015-12-07 kl. 16:57, skrev Zeev Suraski:
-Original Message-
From: Arvids Godjuks [mailto:arvids.godj...@gmail.com]
Sent: Monday, December 07, 2015 5:52 PM
To: Zeev Suraski
Cc: Rowan Collins; PHP internals
Subject: Re: [PHP-DEV] Re: PHP 5.6 life cycle
According to PHP release RFC - t
Den 2015-12-06 kl. 18:05, skrev Sebastian Bergmann:
Am 06.12.2015 um 17:57 schrieb Björn Larsson:
Would like to add that given 7.0 major uptake with ISP's coming next
year (at least in my region) it seems prudent to prolong 5.6 lifecycle a
little.
I fear that extending support for PHP 5 will
Hi Matt,
Matt Wilmas wrote:
Hi Bob, all,
After this commit:
http://git.php.net/?p=php-src.git;a=commitdiff;h=509712c7d9056b4ceb50134bfeea1a1115720744
In streamsfuncs.c, line 996 has an extra comma; and line 1511 has #ifdef
instead of #ifndef ...
BTW, maybe with the changes I'll propose, all
Hi Bob, all,
After this commit:
http://git.php.net/?p=php-src.git;a=commitdiff;h=509712c7d9056b4ceb50134bfeea1a1115720744
In streamsfuncs.c, line 996 has an extra comma; and line 1511 has #ifdef
instead of #ifndef ...
BTW, maybe with the changes I'll propose, all this extra FAST_ZPP stuff
This is the current official timeline
http://php.net/supported-versions.php
I personally think it is long enough and would actually suggestion
shortening it (2016, not 2017). Extended the timeline would only further
influence people not to upgrade, as an excuse that it was still supported.
On Mo
Hi Anatol, all,
CFG's effect on Wordpress at the end... :-/
- Original Message -
From: "Anatol Belski"
Sent: Wednesday, November 25, 2015
Hi Matt,
I wonder really how much research you do :)
Not much on this... Hope there aren't major inaccuracies.
I just came across stuff while d
Hi Anatol,
- Original Message -
From: "Anatol Belski"
Sent: Wednesday, November 25, 2015
Hi Matt,
-Original Message-
From: Matt Wilmas [mailto:php_li...@realplain.com]
Sent: Monday, November 23, 2015 8:15 AM
To: Anatol Belski ; internals@lists.php.net;
internals-
w...@lists.
Zeev Suraski wrote on 07/12/2015 15:11:
It's always possible to submit another RFC to alter the end date, even if
we decide about one now. But I do think it'll send a different message -
that we think it's going to take extraordinary circumstances for us to
change the decision - vs. us saying "
> -Original Message-
> From: Arvids Godjuks [mailto:arvids.godj...@gmail.com]
> Sent: Monday, December 07, 2015 5:52 PM
> To: Zeev Suraski
> Cc: Rowan Collins; PHP internals
> Subject: Re: [PHP-DEV] Re: PHP 5.6 life cycle
>
> According to PHP release RFC - the date is already set. To extend
2015-12-07 17:11 GMT+02:00 Zeev Suraski :
> > -Original Message-
> > From: Rowan Collins [mailto:rowan.coll...@gmail.com]
> > Sent: Monday, December 07, 2015 4:42 PM
> > To: internals@lists.php.net
> > Subject: Re: [PHP-DEV] Re: PHP 5.6 life cycle
> >
> > Rowan Collins wrote on 07/12/2015
> -Original Message-
> From: Rowan Collins [mailto:rowan.coll...@gmail.com]
> Sent: Monday, December 07, 2015 4:42 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: PHP 5.6 life cycle
>
> Rowan Collins wrote on 07/12/2015 14:35:
> > - On what factors will the decision be based?
On 07/12/15 14:42, Rowan Collins wrote:
> Rowan Collins wrote on 07/12/2015 14:35:
>> - On what factors will the decision be based? If the reason to delay
>> the decision is lack of information, what information are we planning
>> to use? Are there metrics we can use to make a more objective decisi
OS's (CentOS/Debian) for example do offer official upgrade paths via their
own repositories and 3rd party repositories. However has history has shown
extended support only extends the resistance to update those paths, Alain
Williams
While the PHP Development Team obviously cannot control the acti
Rowan Collins wrote on 07/12/2015 14:35:
- On what factors will the decision be based? If the reason to delay
the decision is lack of information, what information are we planning
to use? Are there metrics we can use to make a more objective decision?
Come to think, this works the other way a
Sebastian Bergmann wrote on 07/12/2015 14:28:
Exactly. We need a fixed EOL date and we need it now. And before this
thread started we had one: August 2017.
To be fair, it wouldn't have taken a psychic to predict that this would
be at least discussed. Until now, there has never actually been a
2016, not 2017. Extended support for nearly 2 years is a bad idea and only
further enables bad practices.
On Mon, Dec 7, 2015 at 9:32 AM, Adam Howard wrote:
> I see the same people who had a problem with the EOL (end of life) date
> for 5.4, 5.5, are going to be the same people who have a probl
Andrea Faulds wrote on 07/12/2015 14:16:
Furthermore, postponing EOL now means reduced pressure to upgrade to
7. If people feel they do not have to move any time soon, perhaps they
won't.
So, I wonder if it would not be better to wait until nearer the
deadline, and see if we need an extension
On Mon, Dec 07, 2015 at 12:17:55PM +0200, Arvids Godjuks wrote:
> Hello internals,
>
> In my opinion, right now what dictates the timeframes is Release Process
> RFC: https://wiki.php.net/rfc/releaseprocess
> It clearly states the rules of how things are done.
> If dates for the PHP 5.6 are to be
I see the same people who had a problem with the EOL (end of life) date for
5.4, 5.5, are going to be the same people who have a problem with 5.6 EOL.
Extended the support will only enable those and others to validate their
excuse for not needing to migrate to the new code base.
I agree, a date sh
Am 07.12.2015 um 15:25 schrieb Levi Morrison:
>> So, I wonder if it would not be better to wait until nearer the deadline,
>> and see if we need an extension then?
>
> This is exactly the strategy that at least a few others in this thread
> aside from myself are advocating against. Please let's ju
> So, I wonder if it would not be better to wait until nearer the deadline,
> and see if we need an extension then?
This is exactly the strategy that at least a few others in this thread
aside from myself are advocating against. Please let's just pick an
EOL date and stick to it. By planning to re
Hi,
Jan Ehrhardt wrote:
See http://php.net/supported-versions.php
Will PHP 5.6 go into 'security fixes only' on 28 Aug 2015 with a end of
life on 28 Aug 2016? Or will we be postponing this a couple of months?
As others have pointed out, you made a typo.
PHP 5.6 goes into 'security fixes only'
Hi Stas,
Stanislav Malyshev wrote:
Hi!
IMHO, I think we need to look at the 5.6 lifecycle very differently from
how we look at 5.5 and earlier. This is really the 5.x lifecycle as it's
the last version that's relatively completely painless to upgrade to from
5.x (especially 5.3 and later).
Adding extended support does justify (provide an excuse) for others not
adapt or upgrade to new code. While PHP Development obvious cannot control
the actions of others (obviously), extending support does unintentionally
enables poor practices. Once support is ended, people do begin to migrate.
On 07/12/15 12:09, Rowan Collins wrote:
> Lester Caine wrote on 07/12/2015 11:47:
>> Things are certainly heading in the right direction, but 5.2/3 is still
>> only dropped bellow 50% in the last month, while PHP4 was well down when
>> the actual EOL was proposed. 80% of people were using PHP5.2 in
>
>
> Ferenc - do you still feel strongly that we should defer the decision into
> a later time? I want to know whether to include that as an option in the
> RFC. Personally - while there are pros and cons to both directions, I'm
> leaning more towards having a clearly defined timeline that we de
Lester Caine wrote on 07/12/2015 11:47:
Things are certainly heading in the right direction, but 5.2/3 is still
only dropped bellow 50% in the last month, while PHP4 was well down when
the actual EOL was proposed. 80% of people were using PHP5.2 in 2010
against 20% on PHP4, and that swung to 90/1
On 07/12/15 11:18, Rowan Collins wrote:
> Lester Caine wrote on 07/12/2015 09:42:
>> Providing PHP7 clean alternatives with usable upgrade paths is the
>> only way that PHP5.2/3 can be deprecated fully, so any debate on an
>> arbitrary EOL for 5.6 is simple pie in the sky? When will Python2
>> disa
Lester Caine wrote on 07/12/2015 09:42:
Providing PHP7 clean alternatives with usable upgrade paths is the
only way that PHP5.2/3 can be deprecated fully, so any debate on an
arbitrary EOL for 5.6 is simple pie in the sky? When will Python2
disappear ... now unlikely it ever will? Is PHP5.2 any
> -Original Message-
> From: Derick Rethans [mailto:der...@php.net]
> Sent: Monday, December 07, 2015 12:41 PM
> To: David Zuelke
> Cc: Anatol Belski; Larry Garfield; internals@lists.php.net
> Subject: Re: [PHP-DEV] PHP 5.6 life cycle
>
> On Mon, 7 Dec 2015, David Zuelke wrote:
>
> > On 06.
On Mon, 7 Dec 2015, David Zuelke wrote:
> On 06.12.2015, at 20:38, Anatol Belski wrote:
>
> > From today's perspective, I'd suggest to extend the security only period of
> > 5.6.
>
> That would be my suggestion too.
>
> End "full" support in, say, December 2016 (a year after 7.0.0), but
> th
On Mon, Dec 7, 2015 at 11:04 AM, Ferenc Kovacs wrote:
>
>
> On Mon, Dec 7, 2015 at 1:56 AM, David Zuelke wrote:
>
>> On 06.12.2015, at 20:38, Anatol Belski wrote:
>>
>> > From today's perspective, I'd suggest to extend the security only
>> period of 5.6.
>>
>> That would be my suggestion too.
>
Hi Netroby,
> I wrote a small test. to see if it really concurrent processing any tasks.
> the result looks bad. Still single blocking thread.
>
As the RFC already states:
The actual implementation of coroutine task schedulers is outside the scope
> of this document. This RFC focuses only on th
Hello internals,
In my opinion, right now what dictates the timeframes is Release Process
RFC: https://wiki.php.net/rfc/releaseprocess
It clearly states the rules of how things are done.
If dates for the PHP 5.6 are to be adjusted, than it requires an RFC
process and should be an exception, not th
On Mon, Dec 7, 2015 at 1:56 AM, David Zuelke wrote:
> On 06.12.2015, at 20:38, Anatol Belski wrote:
>
> > From today's perspective, I'd suggest to extend the security only period
> of 5.6.
>
> That would be my suggestion too.
>
> End "full" support in, say, December 2016 (a year after 7.0.0), bu
On 07/12/15 00:02, Jan Ehrhardt wrote:
>>> Giving everyone until the end of 2017 to update their servers is more
>>> >> than sufficient.
>> >
>> >Sufficient for what? It is a hard fact that people still run 5.3
>> >version. In fact, 2/3 of sites run EOLed versions.
> I know why *we* are still runn
Netroby wrote on 07/12/2015 07:05:
As the RFC said.
https://wiki.php.net/rfc/generator-delegation
The defining feature of Generator functions is their support for
suspending execution for later resumption. This capability gives
applications a mechanism to implement asynchronous and concurrent
arc
Hi Nikita,
Thanks for code review.
All the reported issues should be fixed now.
Thanks. Dmitry.
On Sat, Dec 5, 2015 at 3:02 AM, Dmitry Stogov wrote:
> I've reworked your patch https://github.com/php/php-src/pull/1662
> Actually, you patch was really good. I just re-factored one base
> data-str
46 matches
Mail list logo
