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
2012.09.04. 22:25, Jan Ehrhardt php...@ehrhardt.nl 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,
2012.09.04. 23:31, Lester Caine les...@lsces.co.uk 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 just
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 thought
Hi!
forgot to do reply all :)
On Sep 4, 2012 10:25 PM, Jan Ehrhardt php...@ehrhardt.nl 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
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 php...@ehrhardt.nl wrote:
Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 13:15:50 -0700):
Just call error_reporting() at the beginning of
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
hi,
On Tue, Sep 4, 2012 at 11:32 AM, Lester Caine les...@lsces.co.uk 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
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
On Tue, Sep 4, 2012 at 7:04 AM, Lester Caine les...@lsces.co.uk 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
Sherif Ramadan wrote:
On Tue, Sep 4, 2012 at 7:04 AM, Lester Caine les...@lsces.co.uk 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.
hi Lester,
On Tue, Sep 4, 2012 at 2:51 PM, Lester Caine les...@lsces.co.uk 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
Pierre Joye wrote:
On Tue, Sep 4, 2012 at 2:51 PM, Lester Caineles...@lsces.co.uk 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
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
On 4 September 2012 15:09, Lester Caine les...@lsces.co.uk wrote:
Pierre Joye wrote:
On Tue, Sep 4, 2012 at 2:51 PM, Lester Caineles...@lsces.co.uk 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 ...
On Tue, Sep 4, 2012 at 3:09 PM, Lester Caine les...@lsces.co.uk wrote:
Pierre Joye wrote:
On Tue, Sep 4, 2012 at 2:51 PM, Lester Caineles...@lsces.co.uk 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
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
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
On Tue, Sep 4, 2012 at 9:43 AM, Ferenc Kovacs tyr...@gmail.com wrote:
never heard of that one before.
for example, running
?php
for($i=0;$i100;$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
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 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
On Tue, Sep 4, 2012 at 12:57 PM, Rasmus Lerdorf ras...@lerdorf.com 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
2012.09.04. 18:58, Rasmus Lerdorf ras...@lerdorf.com 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
On Tue, Sep 4, 2012 at 1:34 PM, Ferenc Kovacs tyr...@gmail.com wrote:
2012.09.04. 18:58, Rasmus Lerdorf ras...@lerdorf.com 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
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
On Tue, Sep 4, 2012 at 2:15 PM, Lester Caine les...@lsces.co.uk 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
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
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
On Tue, Sep 4, 2012 at 3:09 PM, Lester Caine les...@lsces.co.uk 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
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_STRICT.
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
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
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 -
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.
You just
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 the
On Jul 23, 2011 2:51 PM, Stas Malyshev smalys...@sugarcrm.com 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
On Sat, Jul 23, 2011 at 11:50 PM, Stas Malyshev smalys...@sugarcrm.com 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
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 smalys...@sugarcrm.com wrote:
Hi!
Now that we've decided to add E_STRICT to E_ALL error mask, the
2011/7/23 Pierre Joye pierre@gmail.com:
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
-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 help developers. So I
tend to think
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 adding a
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
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
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 errors
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
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
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 this.
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 was
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
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
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
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
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 error
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
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
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 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
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
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
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() should
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 using
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 to what we
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
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
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
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
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
will break
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
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
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
-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
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 member
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 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 people to make an
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
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
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 thousands of
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
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
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)
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 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, even
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
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
Andi Gutmans wrote:
a) Not using var for member variables but moving to PPP.
b) Not using is_a but using instanceof.
c) references usage - things like:
?
function f() {...}
function r() {...}
$a = f(); //OK
$b =r(); //OK
$a =f(); //warning - function returns value but reference
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 variables but
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
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,
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 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 marked
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. It seems
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 people
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
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.
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
95 matches
Mail list logo
