OK, apparently we will continue the discussion her.
Pierre Joye in php.internals (Wed, 5 Sep 2012 13:15:43 +0200):
>On Sep 4, 2012 10:25 PM, "Jan Ehrhardt" wrote:
>>
>> Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 13:15:50 -0700):
>> >Just call error_reporting() at the beginning of your scri
Hi!
forgot to do reply all :)
On Sep 4, 2012 10:25 PM, "Jan Ehrhardt" wrote:
>
> Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 13:15:50 -0700):
> >Just call error_reporting() at the beginning of your script.
>
> Which ain't possible in drupal (or hardly). You do not write any code.
> You jus
Ferenc Kovacs wrote:
>Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 13:15:50 -0700):
> >Just call error_reporting() at the beginning of your script.
>
>Which ain't possible in drupal (or hardly). You do not write any code.
>You just click together modules, written by others.
Oh, I though
2012.09.04. 23:31, "Lester Caine" ezt írta:
>
> Jan Ehrhardt wrote:
>>
>> Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 13:15:50 -0700):
>>>
>>> >Just call error_reporting() at the beginning of your script.
>
>
>> Which ain't possible in drupal (or hardly). You do not write any code.
>> You ju
2012.09.04. 22:25, "Jan Ehrhardt" ezt írta:
>
> Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 13:15:50 -0700):
> >Just call error_reporting() at the beginning of your script.
>
> Which ain't possible in drupal (or hardly). You do not write any code.
> You just click together modules, written b
Jan Ehrhardt wrote:
Lester Caine in php.internals (Tue, 04 Sep 2012 22:30:34 +0100):
Jan Ehrhardt wrote:
Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 13:15:50 -0700):
Just call error_reporting() at the beginning of your script.
Which ain't possible in drupal (or hardly). You do not wri
Lester Caine in php.internals (Tue, 04 Sep 2012 22:30:34 +0100):
>Jan Ehrhardt wrote:
>> Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 13:15:50 -0700):
>>> >Just call error_reporting() at the beginning of your script.
>
>> Which ain't possible in drupal (or hardly). You do not write any code.
>
Jan Ehrhardt wrote:
Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 13:15:50 -0700):
>Just call error_reporting() at the beginning of your script.
Which ain't possible in drupal (or hardly). You do not write any code.
You just click together modules, written by others.
Actually Jan - Rasm
Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 13:15:50 -0700):
>Just call error_reporting() at the beginning of your script.
Which ain't possible in drupal (or hardly). You do not write any code.
You just click together modules, written by others.
Jan
--
PHP Internals - PHP Runtime Developm
Hi!
> I keep being told that there is nothing wrong with E_STRICT, and again
> someone
> has said that it does NOT cause crashes. I beg to differ here - IT DOES!
If you have a scenario where E_STRICT causes PHP to crash - please
submit a bug to bugs.php.net. If this is your application that is
On 09/04/2012 12:20 PM, Jan Ehrhardt wrote:
> Now that you have changed the subject, I feel free to break in with a
> voice from userland.
>
> Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 09:57:59 -0700):
>> Even with E_STRICT off (...)
>
> Sometimes it is not easy for users to turn off E_ST
On Tue, Sep 4, 2012 at 3:09 PM, Lester Caine wrote:
> Joomla doesn't use either anyway, and neither do a number of the other sites
> I've been porting, but we still get problems.
Well, just to be sure, have you searched the entire codebase of one of
the existing sites experiencing the issues for
Now that you have changed the subject, I feel free to break in with a
voice from userland.
Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 09:57:59 -0700):
>Even with E_STRICT off (...)
Sometimes it is not easy for users to turn off E_STRICT. Lester already
mentioned one scenario: ISP's tend to
Adam Richardson wrote:
If I have any custom error handling I don't know about it. I don't think
>ADOdb or SMARTY adds anything, and I don't load anything.
Well, Smarty can influence error handling:
http://www.smarty.net/docs/en/api.mute.expected.errors.tpl
I think I am right in saying that this
On Tue, Sep 4, 2012 at 2:15 PM, Lester Caine wrote:
> Adam Richardson wrote:
>>
>> I was second-guessing my recall I had a similar issue way back, after
>> Rasmus pointed out that the custom error handler is called even if
>> E_STRICT is off. However, I just looked back at my framework code, I
>>
Adam Richardson wrote:
I was second-guessing my recall I had a similar issue way back, after
Rasmus pointed out that the custom error handler is called even if
E_STRICT is off. However, I just looked back at my framework code, I
see I'm checking to make sure the error level matches, just as Feren
On Tue, Sep 4, 2012 at 1:34 PM, Ferenc Kovacs wrote:
>
> 2012.09.04. 18:58, "Rasmus Lerdorf" ezt írta:
>
>
>>
>> On 09/04/2012 09:36 AM, Adam Richardson wrote:
>> > I think Ferenc is correct in that this sounds like there's a custom
>> > error handler somewhere. If the custom error handler collec
2012.09.04. 18:58, "Rasmus Lerdorf" ezt írta:
>
> On 09/04/2012 09:36 AM, Adam Richardson wrote:
> > I think Ferenc is correct in that this sounds like there's a custom
> > error handler somewhere. If the custom error handler collects error
> > info and then throws an exception (as has been detail
On Tue, Sep 4, 2012 at 12:57 PM, Rasmus Lerdorf wrote:
> Only on a new E_STRICT. Even with E_STRICT off by default, custom error
> handlers are still called, and I think Lester said that turning E_STRICT
> off made it work. So if this is the cause, then it has nothing to do
> with E_STRICT being i
On 09/04/2012 09:36 AM, Adam Richardson wrote:
> I think Ferenc is correct in that this sounds like there's a custom
> error handler somewhere. If the custom error handler collects error
> info and then throws an exception (as has been detailed in various
> blog posts as one manner of unifying the
Ferenc Kovacs wrote:
Using third party code - joomla - only difference between working and not
working is switching E_STRICT on. With display_errors=off one gets a white
screen. I was not surprised as I've had this all the way through with code
from many sources. Yes a lot of the
On Tue, Sep 4, 2012 at 9:43 AM, Ferenc Kovacs wrote:
> never heard of that one before.
>
> for example, running
> for($i=0;$i<100;$i++){
> $foo="foo_".$i;
> ${$foo}->bar = 123;
> }
> echo "done";
>
> gives me 100 E_STRICT, but still executes just fine and prints "done" at
> the end.
> the onl
>
>
> Using third party code - joomla - only difference between working and not
> working is switching E_STRICT on. With display_errors=off one gets a white
> screen. I was not surprised as I've had this all the way through with code
> from many sources. Yes a lot of the time you just get the error
Peter Lind wrote:
From php.ini:
; display_errors
; Default Value: On
; Development Value: On
; Production Value: Off
In a production environment with display_errors off, E_STRICT doesn't
crash anything. Actually, even with it on, it doesn't crash anything -
shitty code does, by creating n
On Tue, Sep 4, 2012 at 3:09 PM, Lester Caine wrote:
> Pierre Joye wrote:
>
>> On Tue, Sep 4, 2012 at 2:51 PM, Lester Caine wrote:
>>
>> >??? OH YES IT DOES !!!
>>> >MANY times I get a a few lines of text on a white screen ...
>>> >Switch off E_STRICT and everything works fine ... as it was on P
On 4 September 2012 15:09, Lester Caine wrote:
> Pierre Joye wrote:
>>
>> On Tue, Sep 4, 2012 at 2:51 PM, Lester Caine wrote:
>>
>>> >??? OH YES IT DOES !!!
>>> >MANY times I get a a few lines of text on a white screen ...
>>> >Switch off E_STRICT and everything works fine ... as it was on PHP5.2
Am Dienstag, 4. September 2012 um 15:09 schrieb Lester Caine:
> I keep being told that there is nothing wrong with E_STRICT, and again
> someone
> has said that it does NOT cause crashes. I beg to differ here - IT DOES!
> Now if you are saying that I need to document these crashes as they SHOULD
Pierre Joye wrote:
On Tue, Sep 4, 2012 at 2:51 PM, Lester Caine wrote:
>??? OH YES IT DOES !!!
>MANY times I get a a few lines of text on a white screen ...
>Switch off E_STRICT and everything works fine ... as it was on PHP5.2
If you have any doubts about how to configure your development or
hi Lester,
On Tue, Sep 4, 2012 at 2:51 PM, Lester Caine wrote:
> ??? OH YES IT DOES !!!
> MANY times I get a a few lines of text on a white screen ...
> Switch off E_STRICT and everything works fine ... as it was on PHP5.2
If you have any doubts about how to configure your development or
produc
Sherif Ramadan wrote:
On Tue, Sep 4, 2012 at 7:04 AM, Lester Caine wrote:
Pierre Joye wrote:
How many of the major PHP user projects ARE currently strict compliant?
And
how many are still requiring E_STRICT switched off in PHP5.4?
This is a development and very useful. PHP does not enforce
On Tue, Sep 4, 2012 at 7:04 AM, Lester Caine wrote:
> Pierre Joye wrote:
>>>
>>> How many of the major PHP user projects ARE currently strict compliant?
>>> And
>>> >how many are still requiring E_STRICT switched off in PHP5.4?
>>
>> This is a development and very useful. PHP does not enforce this
Pierre Joye wrote:
How many of the major PHP user projects ARE currently strict compliant? And
>how many are still requiring E_STRICT switched off in PHP5.4?
This is a development and very useful. PHP does not enforce this mode.
And like any other errors, it only ends in your logs.
But this has
hi,
On Tue, Sep 4, 2012 at 11:32 AM, Lester Caine wrote:
> How many of the major PHP user projects ARE currently strict compliant? And
> how many are still requiring E_STRICT switched off in PHP5.4?
This is a development and very useful. PHP does not enforce this mode.
And like any other errors
Gustavo Lopes wrote:
Second, E_STRICT exists to encourage good OOP practices. There is a lot of code
that generates E_STRICT that does what it was intended to do (ask Lester). By
definition, code that's not supposed to generate E_STRICT messages but does is
buggy, but the fact that some code rais
Hi Folks:
On Sun, Jul 24, 2011 at 12:18:51AM +0200, Ferenc Kovacs wrote:
>
> first of all, 1 think it would be better to change only one thing at a
> time (add E_STRICT to E_ALL), and we also exclude E_DEPRECATED for
> production, which would imo much more important for most apps than
> fixing th
>-Original Message-
>From: Pierre Joye [mailto:pierre@gmail.com]
>Sent: Saturday, July 23, 2011 3:22 PM
>To: Stas Malyshev
>Cc: PHP Internals
>Subject: Re: [PHP-DEV] E_STRICT in production
>
>hi Stas,
>
>The idea of E_STRICT when we introduced it was to
2011/7/23 Pierre Joye :
> hi Stas,
>
> The idea of E_STRICT when we introduced it was to help developers. So
> I tend to think that we should not enable it in php.ini-production.
>
Agreed.
--
Regards,
Felipe Pena
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: ht
hi Stas,
The idea of E_STRICT when we introduced it was to help developers. So
I tend to think that we should not enable it in php.ini-production.
On Sat, Jul 23, 2011 at 11:50 PM, Stas Malyshev wrote:
> Hi!
>
> Now that we've decided to add E_STRICT to E_ALL error mask, the question is
> - what
On Sat, Jul 23, 2011 at 11:50 PM, Stas Malyshev wrote:
> Hi!
>
> Now that we've decided to add E_STRICT to E_ALL error mask, the question is
> - what should we put in recommended production INI - should we include
> E_STRICT or not?
> Development has E_STRICT anyway, so no question there.
I think
On Jul 23, 2011 2:51 PM, "Stas Malyshev" wrote:
> Now that we've decided to add E_STRICT to E_ALL error mask, the question
is - what should we put in recommended production INI - should we include
E_STRICT or not?
> Development has E_STRICT anyway, so no question there.
I can't look it up easily
On Fri, 14 Jul 2006, Greg Beaver wrote:
> Sean Coates wrote:
> > Ilia Alshanetsky wrote:
> >
> >>Why not just define your own custom error handler and have it filter out
> >>the error messages that you don't want to see... To me this would seem
> >>like a easier approach, i would be against addin
Sean Coates wrote:
Ilia Alshanetsky wrote:
Why not just define your own custom error handler and have it filter out
the error messages that you don't want to see... To me this would seem
like a easier approach, i would be against adding a in-language filter
for this.
Inability to easily dete
Sean Coates wrote:
> Ilia Alshanetsky wrote:
>
>>Why not just define your own custom error handler and have it filter out
>>the error messages that you don't want to see... To me this would seem
>>like a easier approach, i would be against adding a in-language filter
>>for this.
>
>
> Inability
Ilia Alshanetsky wrote:
> Why not just define your own custom error handler and have it filter out
> the error messages that you don't want to see... To me this would seem
> like a easier approach, i would be against adding a in-language filter
> for this.
Inability to easily determine which error
On Jul 12, 2006, at 11:56 AM, Lukas Smith wrote:
Therefore my proposal would be to simply add a defined "header" to all
E_STRICT messages that contains the PHP version in which this E_STRICT
message was added.
Hi Lukas,
An alternative might be to implement numerical error code identifiers
Hello Ilia,
Wednesday, July 12, 2006, 9:20:02 PM, you wrote:
> Why not just define your own custom error handler and have it filter
> out the error messages that you don't want to see... To me this would
> seem like a easier approach, i would be against adding a in-language
> filter for thi
Hello Ilia,
Thursday, July 13, 2006, 2:15:48 AM, you wrote:
> On 12-Jul-06, at 7:23 PM, Lukas Smith wrote:
>> Hosters are always behind 1 or 2 minor versions, at best.
> That's an optimistic outlook, on average they are 5-6 versions behind.
Ilia, 5 - 6 minor version behine means that hosters t
On 12-Jul-06, at 7:23 PM, Lukas Smith wrote:
Hosters are always behind 1 or 2 minor versions, at best.
That's an optimistic outlook, on average they are 5-6 versions behind.
Ilia Alshanetsky
Hello,
On 7/13/06, Lukas Smith <[EMAIL PROTECTED]> wrote:
Strict Standards: Declaration of Europe::get_countries() should be
compatible with that of Scandinavia::get_countries() in - on line 14
So I dont really see where its killing a fly with a tank either.
That's why I said it is killing a
Pierre wrote:
if foo-1.2.1 is E_STRICT compliant with 5.1.4 and foo-1.2.2 with
5.2.0, update to 1.2.2 must be the way. It is the safest way, the past
shown us that some E_STRICT can be related to (sometimes critical)
bugs and we should treat them as bugs. Also, I do not like the
additions of ped
Antony Dovgal wrote:
Well, that's what major versions are for, right?
Bugfix releases are for bugfixes, while major versions may introduce new
things and features.
Err we add features in minor (and even patch level) versions all the time.
Sorry, I still fail to see a reason to "filter" erro
On 13.07.2006 02:37, Lukas Smith wrote:
Antony Dovgal wrote:
Lukas, I thought we already discussed and agreed that the only
acceptable solution is NOT to add any E_STRICT messages if the
recommended way didn't exist in first release of the major version.
This apparently requires versioning an
Antony Dovgal wrote:
Lukas, I thought we already discussed and agreed that the only
acceptable solution is NOT to add any E_STRICT messages if the
recommended way didn't exist in first release of the major version.
This apparently requires versioning and its support in PEAR.
And personally I t
On 12.07.2006 19:56, Lukas Smith wrote:
Hi,
PEAR is currently in the process of deciding from when on we want to
mandate PHP5 as the target platform. Currently it looks like sometime in
the next 3-6 months we will likely only accept PHP5 only packages.
We are also pondering how to best appro
Why not just define your own custom error handler and have it filter
out the error messages that you don't want to see... To me this would
seem like a easier approach, i would be against adding a in-language
filter for this.
Ilia Alshanetsky
Hello,
On 7/12/06, Lukas Smith <[EMAIL PROTECTED]> wrote:
Adding such a filter API into PHP internals however seems like a
considerably effort. Therefore my proposal would be to simply add a
defined "header" to all E_STRICT messages that contains the PHP version
in which this E_STRICT message w
Hello Christian,
Wednesday, September 21, 2005, 10:37:01 PM, you wrote:
> Marcus Boerger wrote:
>> [EMAIL PROTECTED] /usr/src/PHP_5_1 $ php -r 'class T{function f($x){}} class
>> U extends T{function f($x=2){}}'
>> make: `sapi/cli/php' is up to date.
>>
>> Strict Standards: Declaration of U::f(
Christian Schneider wrote:
Even more so for function V::f($x,$y=false) to
provide extended functionality to T::f($x) for code which knows about it
Ok, forget that part, I made a typo when testing this ;-)
Apologies,
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscrib
Marcus Boerger wrote:
[EMAIL PROTECTED] /usr/src/PHP_5_1 $ php -r 'class T{function f($x){}} class U
extends T{function f($x=2){}}'
make: `sapi/cli/php' is up to date.
Strict Standards: Declaration of U::f() should be compatible with that of
T::f() in Command line code on line 1
[EMAIL PROTECT
Hello Sean,
Wednesday, September 21, 2005, 4:54:31 PM, you wrote:
> Hello all,
> This crept up as the result of a bug report (not mine --
> http://bugs.php.net/34494), and a small discussion on IRC:
> Why does an E_STRICT get raised when extending a class, and altering the
> method's proto defa
Jani Taskinen wrote:
I don't really understand how removing a deprecated function
would hurt anyone..doesn't all people test their scripts before
putting new PHP version into production?
You seem to be forgetting that the people in charge of the PHP
installation and the ones doing the
On Sun, Nov 30, 2003 at 01:39:13PM +0100, Derick Rethans wrote :
> On Sun, 30 Nov 2003, Markus Fischer wrote:
> > On Wed, Nov 19, 2003 at 12:00:30AM +0200, Andi Gutmans wrote :
> > > I added an E_STRICT error level today which purists can use to make sure
> > > that there scripts are using the lat
On Sun, 30 Nov 2003, Markus Fischer wrote:
> On Wed, Nov 19, 2003 at 12:00:30AM +0200, Andi Gutmans wrote :
> > Hey,
> >
> > I added an E_STRICT error level today which purists can use to make sure
> > that there scripts are using the latest and greatest suggested method of
> > coding (according t
On Wed, Nov 19, 2003 at 12:00:30AM +0200, Andi Gutmans wrote :
> Hey,
>
> I added an E_STRICT error level today which purists can use to make sure
> that there scripts are using the latest and greatest suggested method of
> coding (according to what we decide).
> Ideas are things like:
> a) Not
Alan Knowles wrote:
How about removing the depreciated functions completely, and providing
a userside implementation of them..
include_once 'depreciated.php';
That works for functions at least.. , pass-by-ref is a bit more complex..
At least it gets the mess out of the C code, and it provides
How about removing the depreciated functions completely, and providing a
userside implementation of them..
include_once 'depreciated.php';
That works for functions at least.. , pass-by-ref is a bit more complex..
At least it gets the mess out of the C code, and it provides a simple
answer to a
Derek Ford wrote:
Andi Gutmans wrote:
That's OK with me.
At 04:42 PM 11/19/2003 -0600, Derek Ford wrote:
Derek Ford wrote:
Andi Gutmans wrote:
At 11:53 AM 11/19/2003 -0500, George Schlossnagle wrote:
I agree with --disable-deprecated, it seems to be the best
option. Do you think it would be
On 19 November 2003 20:34, Steph wrote:
> > Not to branch the discussion, but again: if we never plan on
> > removing functions, why go to the trouble of deprecating them?
> > Deprecation implies it will be removed.
> >
>
> .. and as Andi said earlier, removal without loud and clear warning
>
Andi Gutmans wrote:
That's OK with me.
At 04:42 PM 11/19/2003 -0600, Derek Ford wrote:
Derek Ford wrote:
Andi Gutmans wrote:
At 11:53 AM 11/19/2003 -0500, George Schlossnagle wrote:
I agree with --disable-deprecated, it seems to be the best
option. Do you think it would be relevant to have a
At 09:24 AM 11/20/2003 +0200, Jani Taskinen wrote:
On Thu, 20 Nov 2003, Michael Walter wrote:
>No - NEWS contains way more than that. What I was talking about was a
>file the exclusively contains removed/changed functionality - you might
>not want to skim over the entire NEWS file if solely intere
On Thu, 20 Nov 2003, Michael Walter wrote:
>No - NEWS contains way more than that. What I was talking about was a
>file the exclusively contains removed/changed functionality - you might
>not want to skim over the entire NEWS file if solely interested in BC
>breaking changes (see Wez' post - no
> No one reads the NEWS file.
I do. But then, I'm anally retentive.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Olivier Hill wrote:
Ilia Alshanetsky wrote:
On a related note, since a major PHP version is now being released,
perhaps it is the time to finally remove old deprecated functionality
that in many cases deprecated for years. I propose that we agree on a
certain version as a minimum and remove al
Jani Taskinen wrote:
On Wed, 19 Nov 2003, Michael Walter wrote:
Spotting a missing function is quite easy, your script simply
won't work and give a clear error.. :)
Well, not exactly :) It might just not work anymore at some time in the
future (as you know you never really have 100% code c
On Wed, 19 Nov 2003, Michael Walter wrote:
>> Spotting a missing function is quite easy, your script simply
>> won't work and give a clear error.. :)
>Well, not exactly :) It might just not work anymore at some time in the
>future (as you know you never really have 100% code coverage, eve
So, when upgrading, you just go through the new entries, and grep your
source files for occurences - no big deal.
Where's the missing point? ;)
No one reads the NEWS file.
And everone will get the default answer "read the NEWS" once he
complains :) Or you might even add a notice _in the error
On Nov 19, 2003, at 5:03 PM, Wez Furlong wrote:
So, when upgrading, you just go through the new entries, and grep your
source files for occurences - no big deal.
Where's the missing point? ;)
No one reads the NEWS file.
Many of these deprecations (call_time_pass_by_reference sticks in my
mind) ha
> So, when upgrading, you just go through the new entries, and grep your
> source files for occurences - no big deal.
>
> Where's the missing point? ;)
No one reads the NEWS file.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Spotting a missing function is quite easy, your script simply
won't work and give a clear error.. :)
Well, not exactly :) It might just not work anymore at some time in the
future (as you know you never really have 100% code coverage, even with
unit testing and stuff. it's way less than 1
On Wed, 19 Nov 2003, Steph wrote:
>> Not to branch the discussion, but again: if we never plan on removing
>> functions, why go to the trouble of deprecating them? Deprecation
>> implies it will be removed.
>>
>
>.. and as Andi said earlier, removal without loud and clear warning will
>break thou
Andi Gutmans wrote:
At 11:53 AM 11/19/2003 -0500, George Schlossnagle wrote:
I agree with --disable-deprecated, it seems to be the best option.
Do you think it would be relevant to have a php.ini option for this?
What's the point of deprecating things if you never remove them?
Seems like an
> Not to branch the discussion, but again: if we never plan on removing
> functions, why go to the trouble of deprecating them? Deprecation
> implies it will be removed.
>
.. and as Andi said earlier, removal without loud and clear warning will
break thousands of scripts out there. Making users
On Nov 19, 2003, at 1:37 PM, Andi Gutmans wrote:
At 11:53 AM 11/19/2003 -0500, George Schlossnagle wrote:
I agree with --disable-deprecated, it seems to be the best option.
Do you think it would be relevant to have a php.ini option for this?
What's the point of deprecating things if you never re
At 11:53 AM 11/19/2003 -0500, George Schlossnagle wrote:
I agree with --disable-deprecated, it seems to be the best option. Do you
think it would be relevant to have a php.ini option for this?
What's the point of deprecating things if you never remove them? Seems
like an empty threat. And --di
On Wed, 19 Nov 2003, George Schlossnagle wrote:
>
>On Nov 19, 2003, at 12:59 PM, Derek Ford wrote:
>
>> Andi Gutmans wrote:
>>
>>>
>>> About the deprecation, I think it's OK to have a mode where
>>> deprecated functionality doesn't work, but we should definitely leave
>>> it in for now to allow
On Nov 19, 2003, at 12:59 PM, Derek Ford wrote:
Andi Gutmans wrote:
About the deprecation, I think it's OK to have a mode where
deprecated functionality doesn't work, but we should definitely leave
it in for now to allow people to make an easier transition. Maybe the
best solution is to allow
Andi Gutmans wrote:
At 07:55 PM 11/18/2003 -0500, Mike Robinson wrote:
Ilia Alshanetsky wrote:
> On a related note, since a major PHP version is now being
> released, perhaps it is the time to finally remove old
> deprecated functionality that in many cases deprecated for
> years. I propose that
At 17:20 19/11/2003, Ferdinand Beyer wrote:
On 19 Nov 2003 at 0:00, Andi Gutmans wrote:
> Hey,
>
> I added an E_STRICT error level today which purists can use to
make sure
> that there scripts are using the latest and greatest suggested
method of
> coding (according to what we decide).
> Ideas are
On 19 Nov 2003 at 0:00, Andi Gutmans wrote:
> Hey,
>
> I added an E_STRICT error level today which purists can use to
make sure
> that there scripts are using the latest and greatest suggested
method of
> coding (according to what we decide).
> Ideas are things like:
> a) Not using var for me
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi
I did a quick search in the manual and found a bunch of deprecated functions..
Here are some of them:
mysql_db_query
mysql_listtables
mysql_createdb
mysql_dropdb
mysql_selectdb
mysql_listfields
... and a bunch of other aliases.
call_user_method
c
At 07:55 PM 11/18/2003 -0500, Mike Robinson wrote:
Ilia Alshanetsky wrote:
> On a related note, since a major PHP version is now being
> released, perhaps it is the time to finally remove old
> deprecated functionality that in many cases deprecated for
> years. I propose that we agree on a certain
Ilia Alshanetsky wrote:
> IMHO people will be expecting some functionality breaks if and when
> they upgrade to 5.0, not so when upgrading from 5.0 to 5.1. I believe
> that if we do not make the change now, we'd need to wait for the next
> major functionally altering release to make this change.
Ilia Alshanetsky wrote:
On a related note, since a major PHP version is now being released, perhaps it
is the time to finally remove old deprecated functionality that in many cases
deprecated for years. I propose that we agree on a certain version as a
minimum and remove all deprecated functiona
On November 18, 2003 08:05 pm, Sara Golemon wrote:
> This way cruft is left out of a build by default, but can be easily put
> back in by those who need it. Then with the next version (5.1? / 6.0?) do
> the actual dirty work of taking them out for good. More gentle on the
> scripters.
IMHO peop
> When it comes to removing deprecated functions entirely, I'd favor a
> ./configure option (--enable-deprecated) which would define
> PHP_USE_DEPRECATED. Then those functions could be "removed" with:
>
> #ifdef PHP_USE_DEPRECATED
> .
> .
> .
> #endif
That's pretty much what they do in GTK src.
> On a related note, since a major PHP version is now being released,
perhaps it
> is the time to finally remove old deprecated functionality that in many
cases
> deprecated for years. I propose that we agree on a certain version as a
> minimum and remove all deprecated functionality that was marke
Ilia Alshanetsky wrote:
> On a related note, since a major PHP version is now being
> released, perhaps it is the time to finally remove old
> deprecated functionality that in many cases deprecated for
> years. I propose that we agree on a certain version as a
> minimum and remove all deprecated
On November 18, 2003 07:30 pm, Sara Golemon wrote:
> Is it a good time to dredge up the old topic of making a PHP_DEPALIAS() to
> act like PHP_FALIAS() but throw an E_STRICT error saying that the function
> has been deprecated?
+1
On a related note, since a major PHP version is now being released
On November 18, 2003 05:00 pm, Andi Gutmans wrote:
> If you have any further ideas of stuff which makes sense to add to this
> option let me know. For obvious reasons this will be off by default.
When objects are passed to functions intended for arrays.
Ilia
--
PHP Internals - PHP Runtime Devel
On Wed, 19 Nov 2003, Andi Gutmans wrote:
>Hey,
>
>I added an E_STRICT error level today which purists can use to make sure
>that there scripts are using the latest and greatest suggested method of
>coding (according to what we decide).
>Ideas are things like:
>a) Not using var for member variabl
1 - 100 of 101 matches
Mail list logo
