Hi Internals,
as announced a few weeks ago, we tagged PHP 5.5.0alpha1 on Tuesday. This
release marks the start of 5.5.0 release process.
The packages can be found at:
http://downloads.php.net/dsp
This release includes a dozen new features, such as Generators, List
support in foreach. the
On 2012-11-15, d...@php.net d...@php.net wrote:
Hi Internals,
as announced a few weeks ago, we tagged PHP 5.5.0alpha1 on Tuesday. This
release marks the start of 5.5.0 release process.
The packages can be found at:
http://downloads.php.net/dsp
Windows builds are up at
Hi Sara, any progress with your RFC? Can't wait to see it.
Thanks
Jan Dolecek
juzna...@gmail.com
On Wed, Nov 7, 2012 at 6:41 AM, Sara Golemon poll...@php.net wrote:
Retrying this with reply-to-all. :)
I think it's an awesome moment for PHP and HipHop to work together! :)
I'll summarize
Hi!
Again, though, this is a long way down the road: today's discussion is
purely about deprecation.
So these people using mysql-based code will have for years to live with
applications generating thousands of warnings and not be able to do a
thing about it? How is it good for them?
--
On Thu, Nov 15, 2012 at 2:48 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
Again, though, this is a long way down the road: today's discussion is
purely about deprecation.
So these people using mysql-based code will have for years to live with
applications generating thousands of
On 11/15/2012 11:53 AM, Will Fitch wrote:
On Thu, Nov 15, 2012 at 2:48 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
Again, though, this is a long way down the road: today's discussion is
purely about deprecation.
So these people using mysql-based code will have for years to live
On Thu, Nov 15, 2012 at 3:00 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 11/15/2012 11:53 AM, Will Fitch wrote:
On Thu, Nov 15, 2012 at 2:48 PM, Stas Malyshev smalys...@sugarcrm.com
wrote:
Hi!
Again, though, this is a long way down the road: today's discussion is
purely about
Will,
Actually, no it wouldn't. You still get the overhead of the error, plus
any custom error handlers will be triggered regardless of the
error_reporting setting which depending on the implementation of the
error handler can be quite costly performance-wise.
So what solution is
On 11/15/2012 12:08 PM, Will Fitch wrote:
On Thu, Nov 15, 2012 at 3:00 PM, Rasmus Lerdorf wrote:
Actually, no it wouldn't. You still get the overhead of the error, plus
any custom error handlers will be triggered regardless of the
error_reporting setting which depending on the
On Thu, Nov 15, 2012 at 3:11 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 11/15/2012 12:08 PM, Will Fitch wrote:
On Thu, Nov 15, 2012 at 3:00 PM, Rasmus Lerdorf wrote:
Actually, no it wouldn't. You still get the overhead of the error,
plus
any custom error handlers will be
Hello, chiming in:
So what solution is there to this? Should it not be deprecated? This
same issue (is still happening) with register_globals for us, but it's
acceptable as it has been phased out. Should there be no deprecation
warning now and wait for a future release?
I'd like to see
On 11/15/2012 01:50 PM, Austen Hoogen wrote:
The reason to depreciate and/or cease support for a feature (not the same
Pet peeve of mine. The word is deprecate. Depreciate is a financial term.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On Thu, Nov 15, 2012 at 9:11 PM, Anthony Ferrara ircmax...@gmail.comwrote:
Will,
Actually, no it wouldn't. You still get the overhead of the error, plus
any custom error handlers will be triggered regardless of the
error_reporting setting which depending on the implementation of the
On Thu, Nov 15, 2012 at 6:59 PM, Anthony Ferrara ircmax...@gmail.com wrote:
If it wasn't that active open source projects still have ext/mysql as their
primary connection today, I would agree with you. But we still have open
source projects, major ones, that still rely on it even in their
On 11/15/2012 04:18 PM, Sherif Ramadan wrote:
On Thu, Nov 15, 2012 at 6:59 PM, Anthony Ferrara ircmax...@gmail.com wrote:
If it wasn't that active open source projects still have ext/mysql as their
primary connection today, I would agree with you. But we still have open
source projects,
Sherif,
I'm just trying to understand your reasoning behind this view.
How is telling people it's deprecated, but only in the manual going
to be any different than putting warnings to discourage future use,
but only in the manual?
I'm not saying to put it only in the manual. I'm saying we
The main argument is that we haven't actually made it clear in the
manual that the extension is going to be deprecated. There is a user
note on http://www.php.net/manual/en/book.mysql.php and a This
extension is not recommended for writing new code on
On 14/11/12 03:17, Adam Harvey wrote:
On 14 November 2012 00:07, Anthony Ferrara ircmax...@gmail.com wrote:
There's one important thing that I think you all are missing here. You keep
bringing up that we should just use the normal deprecation process. The
problem is that the deprecation
Hi!
Fatal error: Call to private method a::__setb() from context ''...
Or...
Fatal error: Cannot set private property a::$b.
Which makes more sense to the most people?
Either of these is fine. I'm not talking about that though. You said:
stack traces, reflection, etc would hide the
Hello geeks,
Why does PHP 5.5 remove the *_logo_* functions? Is this a security
related move? Shouldn't these emit E_DEPRECATED errors in 5.5?
Regards,
Philip
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, Nov 15, 2012 at 7:26 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 11/15/2012 04:18 PM, Sherif Ramadan wrote:
On Thu, Nov 15, 2012 at 6:59 PM, Anthony Ferrara ircmax...@gmail.com wrote:
If it wasn't that active open source projects still have ext/mysql as their
primary connection
On 11/15/2012 05:52 PM, Sherif Ramadan wrote:
This was the soft-deprecation notice that I believe was discussed
before the actual steps were to be taken to officially deprecate
ext/mysql. Yes, it's a suggestion, but a clearly worded suggestion,
none-the-less. It has been around for a little
On Thu, Nov 15, 2012 at 7:40 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Sherif,
I'm just trying to understand your reasoning behind this view.
How is telling people it's deprecated, but only in the manual going
to be any different than putting warnings to discourage future use,
but only
On Thu, Nov 15, 2012 at 8:26 PM, Philip Olson phi...@roshambo.org wrote:
Hello geeks,
Why does PHP 5.5 remove the *_logo_* functions? Is this a security
related move? Shouldn't these emit E_DEPRECATED errors in 5.5?
Regards,
Philip
--
PHP Internals - PHP Runtime Development Mailing List
On Thu, Nov 15, 2012 at 9:00 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 11/15/2012 05:52 PM, Sherif Ramadan wrote:
This was the soft-deprecation notice that I believe was discussed
before the actual steps were to be taken to officially deprecate
ext/mysql. Yes, it's a suggestion, but a
*Note:* this email is also available as a gist for easier reading:
https://wiki.php.net/rfc/mysql_deprecation
Sirs, Gentlemen and Scholars,
I am appreciative of all of the discussion that has happened on this
RFC. It has helped me understand how we feel collectively about
ext/mysql and how to
hi Anthony,
On Thu, Nov 15, 2012 at 9:11 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Actually, no it wouldn't. You still get the overhead of the error, plus
any custom error handlers will be triggered regardless of the
error_reporting setting which depending on the implementation of the
27 matches
Mail list logo
