E_STRICT

php.internals

Sara Golemon

22 years ago
> andi Tue Nov 18 04:25:05 2003 EDT > > Modified files: > /ZendEngine2 zend.c zend_builtin_functions.c zend_constants.c > zend_errors.h zend_language_parser.y > Log: > - Add E_STRICT, to be used to warn purists (like Jani :) >
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? Here's a patch for review and discussion: Index: Zend/zend_API.h =================================================================== RCS file: /repository/ZendEngine2/zend_API.h,v retrieving revision 1.169 diff -u -r1.169 zend_API.h --- Zend/zend_API.h 18 Nov 2003 19:18:54 -0000 1.169 +++ Zend/zend_API.h 19 Nov 2003 00:28:55 -0000 @@ -51,6 +51,7 @@ #define ZEND_NAMED_FE(zend_name, name, arg_info) ZEND_FENTRY(zend_name, name, arg_info, 0) #define ZEND_FE(name, arg_info) ZEND_FENTRY(name, ZEND_FN(name), arg_info, 0) #define ZEND_FALIAS(name, alias, arg_info) ZEND_FENTRY(name, ZEND_FN(alias), arg_info, 0) +#define ZEND_DEPALIAS(name, alias, arg_info) ZEND_FENTRY(name, ZEND_FN(alias), arg_info, ZEND_ACC_DEPRECATED | ZEND_ACC_PUBLIC) #define ZEND_ME(classname, name, arg_info, flags) ZEND_FENTRY(name, ZEND_FN(classname##_##name), arg_info, flags) #define ZEND_ABSTRACT_ME(classname, name, arg_info) ZEND_FENTRY(name, NULL, arg_info, ZEND_ACC_PUBLIC|ZEND_ACC_ABSTRACT) #define ZEND_MALIAS(name, classname, alias, arg_info, flags) \ Index: Zend/zend_compile.h =================================================================== RCS file: /repository/ZendEngine2/zend_compile.h,v retrieving revision 1.262 diff -u -r1.262 zend_compile.h --- Zend/zend_compile.h 10 Nov 2003 16:14:44 -0000 1.262 +++ Zend/zend_compile.h 19 Nov 2003 00:28:55 -0000 @@ -100,6 +100,7 @@ #define ZEND_ACC_INTERFACE 0x08 #define ZEND_ACC_ABSTRACT_CLASS 0x10 #define ZEND_ACC_FINAL_CLASS 0x20 +#define ZEND_ACC_DEPRECATED 0x40 /* The order of those must be kept - public < protected < private */ #define ZEND_ACC_PUBLIC 0x100 Index: Zend/zend_execute.c =================================================================== RCS file: /repository/ZendEngine2/zend_execute.c,v retrieving revision 1.549 diff -u -r1.549 zend_execute.c --- Zend/zend_execute.c 10 Nov 2003 16:23:12 -0000 1.549 +++ Zend/zend_execute.c 19 Nov 2003 00:28:55 -0000 @@ -2513,6 +2513,10 @@ NEXT_OPCODE(); /* Never reached */ } + if (EX(function_state).function->common.fn_flags & ZEND_ACC_DEPRECATED) { + zend_error(E_STRICT, "%s() has been deprecated and may be removed in a future version.", EX(function_state).function->common.function_name); + } + zend_ptr_stack_n_push(&EG(argument_stack), 2, (void *) EX(opline)->extended_value, NULL); EX_T(EX(opline)->result.u.var).var.ptr_ptr = &EX_T(EX(opline)->result.u.var).var.ptr; Index: main/php.h =================================================================== RCS file: /repository/php-src/main/php.h,v retrieving revision 1.200 diff -u -r1.200 php.h --- main/php.h 3 Nov 2003 14:12:45 -0000 1.200 +++ main/php.h 19 Nov 2003 00:28:55 -0000 @@ -354,6 +354,7 @@ #define PHP_NAMED_FE ZEND_NAMED_FE #define PHP_FE ZEND_FE #define PHP_FALIAS ZEND_FALIAS +#define PHP_DEPALIAS ZEND_DEPALIAS #define PHP_ME ZEND_ME #define PHP_MODULE_STARTUP_N ZEND_MODULE_STARTUP_N

Ilia A.

22 years ago
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, 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 as such prior to that version. Ilia

Mike Robinson

22 years ago
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 functionality that was > marked as such prior to that version.
I think this is a good idea, and this really should happen before PHP-5 goes gold. The negative impact and effects can be minimized by a prominent entry in the migration and/or NEWS documents. Best Regards Mike Robinson

Sara Golemon

22 years ago
> 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 as such
prior
> to that version. >
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 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. -Sara

Steph

22 years ago
> 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 to work for them :)

Ilia A.

22 years ago
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 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. Which puts this off indefinitely into the far future. Ilia

Mike Robinson

22 years ago
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. Which puts > this off indefinitely into the far future.
Precisely. Might as well just do it and be done with it. Cheers Mike Robinson

Olivier Hill

22 years ago
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 functionality that was marked as such prior > to that version.
Like call-time pass by ref? Oliver
-- GB/E/IT d+ s+:+ a-- C++$ UL++++$ P++++ L+++$ E- W++$ N- ?o ?K w--(---) !O M+$ V- PS+ PE- Y PGP t++ 5-- X+@ R- tv++ b++(+++) DI++++ D+ G++ e+>++ h(*) r y+(?)

T.R. Cox

22 years ago
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 all deprecated functionality >> that was marked as such prior to that version. > > > Like call-time pass by ref? > > Oliver
Has call-time pass by ref really been deprecated for years? I only started seeing this warning with P5. BDKR

Andi Gutmans

22 years ago
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 version as a > > minimum and remove all deprecated functionality that was > > marked as such prior to that version. > >I think this is a good idea, and this really should happen >before PHP-5 goes gold. The negative impact and effects can >be minimized by a prominent entry in the migration and/or >NEWS documents.
Just to make it clear, doing an if() at run-time for E_STRICT isn't something we'd want to do in every place. It's best if we'd do it mostly during compilation stage or only in places at run-time where it really isn't a big deal. Some of the suggestions didn't take this into account. 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 people something like --disable-deprecated which gets rid of them, and connect the deprecated functionality to E_STRICT. Andi

Derek Ford

22 years ago
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 we agree on a certain version as a >> > minimum and remove all deprecated functionality that was >> > marked as such prior to that version. >> >> I think this is a good idea, and this really should happen >> before PHP-5 goes gold. The negative impact and effects can >> be minimized by a prominent entry in the migration and/or >> NEWS documents. > > > Just to make it clear, doing an if() at run-time for E_STRICT isn't > something we'd want to do in every place. It's best if we'd do it > mostly during compilation stage or only in places at run-time where it > really isn't a big deal. Some of the suggestions didn't take this into > account. > > 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 people something like --disable-deprecated which > gets rid of them, and connect the deprecated functionality to E_STRICT. > > Andi >
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?

George Schlossnagle

22 years ago
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 people something like --disable-deprecated >> which gets rid of them, and connect the deprecated functionality to >> E_STRICT. >> >> Andi >> > 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 --disable-deprecated seems like a horrible idea to me - it greatly reduces the portability of scripts and increases the wtf factor by having them runable in some places and not runnable in others. George

Jani Taskinen

22 years ago
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 easier transition. Maybe the >>> best solution is to allow people something like --disable-deprecated >>> which gets rid of them, and connect the deprecated functionality to >>> E_STRICT. >>> >>> Andi >>> >> 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 --disable-deprecated seems like a horrible >idea to me - it greatly reduces the portability of scripts and >increases the wtf factor by having them runable in some places and not >runnable in others.
+infinity....and about having php.ini option: OVER MY DEAD BODY! :) --Jani

Andi Gutmans

22 years ago
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 --disable-deprecated seems like a horrible idea >to me - it greatly reduces the portability of scripts and increases the >wtf factor by having them runable in some places and not runnable in others.
I guess we should stick to only E_STRICT then, and find a nice general way of making deprecated function calls warn people. I don't think we should nuke such functions because it would break all scripts and we should give people a chance to use E_STRICT to track all of this stuff. Maybe we can nuke the stuff for PHP 5.5 but it's not that critical. By nuking the functionality we will hurt more users than we will help users. Andi

George Schlossnagle

22 years ago
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 remove them? >> Seems like an empty threat. And --disable-deprecated seems like a >> horrible idea to me - it greatly reduces the portability of scripts >> and increases the wtf factor by having them runable in some places >> and not runnable in others. > > I guess we should stick to only E_STRICT then, and find a nice general > way of making deprecated function calls warn people. > I don't think we should nuke such functions because it would break all > scripts and we should give people a chance to use E_STRICT to track > all of this stuff. Maybe we can nuke the stuff for PHP 5.5 but it's > not that critical. By nuking the functionality we will hurt more users > than we will help users.
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. George

Steph

22 years ago
> 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 do something special if they want to use their old code, is a much kinder option. It might also kick people into updating those scripts before the deprecated functions actually die.

Jani Taskinen

22 years ago
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 scripts out there. Making users do something special if >they want to use their old code, is a much kinder option. It might also >kick people into updating those scripts before the deprecated functions >actually die.
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? Spotting a missing function is quite easy, your script simply won't work and give a clear error.. :) Maybe the best way to proceed with deprecation is to first start giving the error message warning it's deprecated and in some version remove the functionality and replace the error with one that says something along the lines of: "This function is not here anymore, use foobar() instead." And later remove that too.. --Jani

Michael Walter

22 years ago
> 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 100%, actually ). I don't understand why you can't simply have a special DEPRECATELOG (or just entries in the CHANGELOG) which mention which functions have been deprecated due to which reasons, and which talks about possible "fixes"/replacements, tho- a simple (and hypothetical) example: [PHP 4.3.5] - strlen(): removed, as it would be redundant now that count() is polymorphic. 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? ;) Cheers, Michael

Wez Furlong

22 years ago
> 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.

Jani Taskinen

22 years ago
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 with >unit testing and stuff. it's way less than 100%, actually ). > >I don't understand why you can't simply have a special DEPRECATELOG (or >just entries in the CHANGELOG) which mention which functions have been >deprecated due to which reasons, and which talks about possible >"fixes"/replacements, tho- a simple (and hypothetical) example: > >[PHP 4.3.5] > >- strlen(): removed, as it would be redundant now that count() is > polymorphic. > >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? ;)
Err..we already do this in the NEWS.. (the opposite shows quite well in HEAD, for new functions) --Jani

Christian Schneider

22 years ago
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 scripts aren't always the same. Take ISPs for example. Breaking code which is only included under special circumstances is not something an ISP admin is looking forward to, he'd rather stick to an old (but proven) PHP major version to avoid customer calls on Monday morning. (Sidenote: I prefer to require all and every code of my application in one central location to not fall into that trap. That's why I consider __autoload harmful) - Chris

Derek Ford

22 years ago
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 empty threat. And --disable-deprecated seems like a >> horrible idea to me - it greatly reduces the portability of scripts >> and increases the wtf factor by having them runable in some places >> and not runnable in others. > > > I guess we should stick to only E_STRICT then, and find a nice general > way of making deprecated function calls warn people. > I don't think we should nuke such functions because it would break all > scripts and we should give people a chance to use E_STRICT to track > all of this stuff. Maybe we can nuke the stuff for PHP 5.5 but it's > not that critical. By nuking the functionality we will hurt more users > than we will help users. > > Andi >
I was just told of an old list discussion over E_DEPRECATED. Why not drag that idea back in? I missed it, so I don't know the milk and cookies, but it seems to me to be a good idea.