hi Anthony,
On Thu, Nov 15, 2012 at 9:11 PM, Anthony Ferrara 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
>> > error h
*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 dep
On Thu, Nov 15, 2012 at 9:00 PM, Rasmus Lerdorf 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 clearly worded
On Thu, Nov 15, 2012 at 8:26 PM, Philip Olson 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
> To unsub
On Thu, Nov 15, 2012 at 7:40 PM, Anthony Ferrara 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 in t
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:26 PM, Rasmus Lerdorf wrote:
> On 11/15/2012 04:18 PM, Sherif Ramadan wrote:
>> On Thu, Nov 15, 2012 at 6:59 PM, Anthony Ferrara wrote:
>>
>>>
>>>
>>> If it wasn't that active open source projects still have ext/mysql as their
>>> primary connection today, I would agree
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
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
On 14/11/12 03:17, Adam Harvey wrote:
> On 14 November 2012 00:07, Anthony Ferrara 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 process was never
> 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
> http://www.php.net/manual/en/intro
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 say
On 11/15/2012 04:18 PM, Sherif Ramadan wrote:
> On Thu, Nov 15, 2012 at 6:59 PM, Anthony Ferrara 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
On Thu, Nov 15, 2012 at 6:59 PM, Anthony Ferrara 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 dev
> versions. S
Sherif,
You see, I'm skeptical about this approach. Mainly because I don't see
> how any of that has proven to be the case in the past. Albeit, we've
> never deprecated such a heavily used extension before in the past, but
> still. There remains the issue of "how many people will actually read
> t
On Thu, Nov 15, 2012 at 3:11 PM, Anthony Ferrara wrote:
> 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 han
On Thu, Nov 15, 2012 at 9:11 PM, Anthony Ferrara wrote:
> 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
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: http://www.php.net/un
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?
>>
>>
On Thu, Nov 15, 2012 at 3:11 PM, Rasmus Lerdorf 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 triggered regar
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 i
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 soluti
On Thu, Nov 15, 2012 at 3:00 PM, Rasmus Lerdorf wrote:
> On 11/15/2012 11:53 AM, Will Fitch wrote:
> > On Thu, Nov 15, 2012 at 2:48 PM, Stas Malyshev >wrote:
> >
> >> Hi!
> >>
> >>> Again, though, this is a long way down the road: today's discussion is
> >>> purely about deprecation.
> >>
> >> S
On 11/15/2012 11:53 AM, Will Fitch wrote:
> On Thu, Nov 15, 2012 at 2:48 PM, Stas Malyshev wrote:
>
>> 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
>> ap
On Thu, Nov 15, 2012 at 2:48 PM, Stas Malyshev wrote:
> 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
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?
--
Stani
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 wrote:
> Retrying this with reply-to-all. :)
>
> I think it's an awesome moment for PHP and HipHop to work together! :)
> I'll summarize what we have s
On 2012-11-15, "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
http://windo
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 si
29 matches
Mail list logo
