# Why 5.2 should not be delayed for E_DEPRECATED - Thread: https://externals.io/message/26214 - Original archive: https://news-web.php.net/php.internals/26214 - Started by Ilia Alshanetsky on 2006-10-24T00:33:05+00:00 - Messages: 22 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #26214 — Ilia Alshanetsky — 2006-10-24T00:33:05+00:00 URL: https://externals.io/message/26214#26214 I've been reading people's replies to Marcus' RFC in regard to `E_DEPRECATED` and it seems that some people have expressed the want to delay 5.2 until mucking around with error handling is done one way or another. My simple answer to this is no. The long answer is as follows. PHP 5.2.0 is not the last 5.X release, there will be more patch level versions and at the very least at least one more major version, so we should not be trying to stuff every single feature under the sun into it as if it was the end of the 5 series. Furthermore, it makes little sense to make drastic error handling changes this late in the game, rushing the decision process and possibly excluding developers who do not read the list every day or are currently away. It should go through an extensive peer review and comment process, be tested, tried with real applications to see what breaks and so on, this is not a trivial change. Another words it is too major of a change to do at the last minute, rushing it will only lead to problems we'd end up cleaning up for many more releases to come. We also need to remember that 5.2 is already way behind schedule, which is important because it contains a fair number of security fixes, without which a good number of users are vulnerable to a variety of exploits. Delaying the release means not deploying those fixes and in my opinion is a disservice to all users of PHP. In my opinion we need to make a release, continue considering Marcus' RFC, develop a patch and push it to our real development tree PHP 6.0. If it proves to be solid and does not break (m)any applications it would be the first candidate to back-port to 5 series once 5.3 is under consideration. Ilia Alshanetsky --- ## #26216 — Lester Caine — 2006-10-24T04:17:12+00:00 URL: https://externals.io/message/26214#26216 · In reply to: #26214 Ilia Alshanetsky wrote: > I've been reading people's replies to Marcus' RFC in regard to > `E_DEPRECATED` and it seems that some people have expressed the want to > delay 5.2 until mucking around with error handling is done one way or > another. My simple answer to this is no. SIMPLE QUESTION - I've just been through the exercise of finally moving everything to 5.1.6 after testing everything. I'd dropped back to 5.0.4 simply because 5.0.5 cause problems with nearly all of my sites and could not be used. Are any of the 'rule changes' in 5.2 going to cause the same compatibility problems as 5.0.5 did - if so and `E_DEPRECATED` is the correct state for these changes then it needs sorting before release rather than once again releasing code that just causes problems. At the very least we need a proper statement of what could be broken rather than the comments buried somewhere in the release notes ? -- Lester Caine - G8HFL ----------------------------- L.S.Caine Electronic Services - http://home.lsces.co.uk Model Engineers Digital Workshop - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Treasurer - Firebird Foundation Inc. - http://www.firebirdsql.org/index.php --- ## #26218 — Zeev Suraski — 2006-10-24T06:55:38+00:00 URL: https://externals.io/message/26214#26218 · In reply to: #26214 Ilia, I think Wez's suggestion is the most practical one. Let's make sure we haven't introduced any fatal errors into 5.2 (and demote them to `E_STRICT` for now), and handle the rest of the suggestions afterwards. Zeev At 02:33 24/10/2006, Ilia Alshanetsky wrote: >I've been reading people's replies to Marcus' RFC in regard to >E_DEPRECATED and it seems that some people have expressed the want to >delay 5.2 until mucking around with error handling is done one way or >another. My simple answer to this is no. > >The long answer is as follows. > >PHP 5.2.0 is not the last 5.X release, there will be more patch level >versions and at the very least at least one more major version, so we >should not be trying to stuff every single feature under the sun >into it as if it was the end of the 5 series. Furthermore, it makes >little sense to make drastic error handling changes this late in the >game, rushing the decision process and possibly excluding developers >who do not read the list every day or are currently away. It should >go through an extensive peer review and comment process, be tested, >tried with real applications to see what breaks and so on, this is >not a trivial change. Another words it is too major of a change to do >at the last minute, rushing it will only lead to problems we'd end up >cleaning up for many more releases to come. We also need to remember >that 5.2 is already way behind schedule, which is important because >it contains a fair number of security fixes, without which a good >number of users are vulnerable to a variety of exploits. Delaying the >release means not deploying those fixes and in my opinion is a >disservice to all users of PHP. > >In my opinion we need to make a release, continue considering >Marcus' RFC, develop a patch and push it to our real development tree >PHP 6.0. If it proves to be solid and does not break (m)any >applications it would be the first candidate to back-port to 5 series >once 5.3 is under consideration. > > >Ilia Alshanetsky --- ## #26221 — Lukas Kahwe Smith — 2006-10-24T07:30:58+00:00 URL: https://externals.io/message/26214#26221 · In reply to: #26218 Zeev Suraski wrote: > Ilia, > > I think Wez's suggestion is the most practical one. Let's make sure we > haven't introduced any fatal errors into 5.2 (and demote them to > `E_STRICT` for now), and handle the rest of the suggestions afterwards. +1 I guess this is the best we can go. It might cause some trouble for people developing in E_STRICT, but I also think that 5.2.0 really needs to be in the hands of users. regards, Lukas --- ## #26226 — Ilia Alshanetsky — 2006-10-24T14:23:17+00:00 URL: https://externals.io/message/26214#26226 · In reply to: #26216 For this particular purpose there is a fairly detailed README.UPDATE_5_2 that details the major functionality changes that have happened in PHP 5.2 > Ilia Alshanetsky wrote: > > […] > > SIMPLE QUESTION - I've just been through the exercise of finally > moving everything to 5.1.6 after testing everything. I'd dropped > back to 5.0.4 simply because 5.0.5 cause problems with nearly all > of my sites and could not be used. Are any of the 'rule changes' in > 5.2 going to cause the same compatibility problems as 5.0.5 did - > if so and `E_DEPRECATED` is the correct state for these changes then > it needs sorting before release rather than once again releasing > code that just causes problems. > > At the very least we need a proper statement of what could be > broken rather than the comments buried somewhere in the release > notes ? > > -- > Lester Caine - G8HFL > ----------------------------- > L.S.Caine Electronic Services - http://home.lsces.co.uk > Model Engineers Digital Workshop - http://home.lsces.co.uk/ > ModelEngineersDigitalWorkshop/ > Treasurer - Firebird Foundation Inc. - http://www.firebirdsql.org/ > index.php > > -- > > > > Ilia Alshanetsky --- ## #26227 — Ilia Alshanetsky — 2006-10-24T14:32:21+00:00 URL: https://externals.io/message/26214#26227 · In reply to: #26218 Zeev, There are probably 5-6 new fatal errors in the engine since 5.1, some of which cannot be delegated to lower error reporting modes as they may cause engine instability or similar problems. Rasmus was going to make a list of all the newly added engine error changes, hopefully he'll have that list soon. > Ilia, > > I think Wez's suggestion is the most practical one. Let's make > sure we haven't introduced any fatal errors into 5.2 (and demote > them to `E_STRICT` for now), and handle the rest of the suggestions > afterwards. > > Zeev > > At 02:33 24/10/2006, Ilia Alshanetsky wrote: > > […] > > -- > > > > Ilia Alshanetsky --- ## #26228 — Rasmus Lerdorf — 2006-10-24T14:35:25+00:00 URL: https://externals.io/message/26214#26228 · In reply to: #26227 Ilia Alshanetsky wrote: > Zeev, > > There are probably 5-6 new fatal errors in the engine since 5.1, some of > which cannot be delegated to lower error reporting modes as they may > cause engine instability or similar problems. Rasmus was going to make a > list of all the newly added engine error changes, hopefully he'll have > that list soon. It's 7:30am here. Hold your horses. I have a couple of meetings this morning and will get to it after those. -Rasmus --- ## #26229 — Zeev Suraski — 2006-10-24T14:38:53+00:00 URL: https://externals.io/message/26214#26229 · In reply to: #26227 Well I'm definitely not referring to those, only the new strict OO fatals as per Marcus's original message... Zeev At 16:32 24/10/2006, Ilia Alshanetsky wrote: >Zeev, > >There are probably 5-6 new fatal errors in the engine since 5.1, some >of which cannot be delegated to lower error reporting modes as they >may cause engine instability or similar problems. Rasmus was going to >make a list of all the newly added engine error changes, hopefully >he'll have that list soon. > > > > > > […] > >Ilia Alshanetsky --- ## #26230 — Hannes Magnusson — 2006-10-24T14:57:29+00:00 URL: https://externals.io/message/26214#26230 · In reply to: #26227 > Zeev, > > There are probably 5-6 new fatal errors in the engine since 5.1, some > of which cannot be delegated to lower error reporting modes as they > may cause engine instability or similar problems. Rasmus was going to > make a list of all the newly added engine error changes, hopefully > he'll have that list soon. Attached is a list (php examples) over all the backwards incompatible error throwing I could find... -Hannes > > > > > > […] > > Ilia Alshanetsky --- ## #26231 — Zeev Suraski — 2006-10-24T15:10:46+00:00 URL: https://externals.io/message/26214#26231 · In reply to: #26230 I think that a lot of those are legit - we only need to 'demote' the language-level warnings/errors that attempt to enforce strict OO standards. Warnings/errors that warn about unacceptable input are legitimate and should stay. Zeev At 16:57 24/10/2006, Hannes Magnusson wrote: > > > […] > >Attached is a list (php examples) over all the backwards incompatible >error throwing I could find... >-Hannes > > > > > […] > > >Content-Type: text/plain; name="backwards.incompatible.error.throwing.txt" >Content-Disposition: attachment; >filename="backwards.incompatible.error.throwing.txt" >X-Attachment-Id: f_etof8h3u --- ## #26232 — Ilia Alshanetsky — 2006-10-24T15:13:09+00:00 URL: https://externals.io/message/26214#26232 · In reply to: #26231 Some OO errors like using iterators by reference and throwing exceptions out of __toString() are ligit as well, doing so would/ could cause problems. > I think that a lot of those are legit - we only need to 'demote' > the language-level warnings/errors that attempt to enforce strict > OO standards. > Warnings/errors that warn about unacceptable input are legitimate > and should stay. > > Zeev > > At 16:57 24/10/2006, Hannes Magnusson wrote: > > […] > > Ilia Alshanetsky --- ## #26233 — Zeev Suraski — 2006-10-24T15:18:06+00:00 URL: https://externals.io/message/26214#26233 · In reply to: #26232 Right. Zeev At 17:13 24/10/2006, Ilia Alshanetsky wrote: >Some OO errors like using iterators by reference and throwing >exceptions out of __toString() are ligit as well, doing so would/ >could cause problems. > > > > > > […] > >Ilia Alshanetsky --- ## #26234 — Marcus Boerger — 2006-10-24T18:55:24+00:00 URL: https://externals.io/message/26214#26234 · In reply to: #26232 Hello Ilia, both, the __toString and the iterator in foreach by reference would put the engine into an unstable state. That saiditis very important that we do not blindley change error modes here. Most changes havebeen done for a good reason. And most of those were added lately because we are always pushing to fast with releases so that we only after releasing find out whatis causing problems. And at that time peoplealready started to use those 'features' andscream if we have to remove them. Just keep this in mind - please. best regards marcus Tuesday, October 24, 2006, 5:13:09 PM, you wrote: > Some OO errors like using iterators by reference and throwing > exceptions out of __toString() are ligit as well, doing so would/ > could cause problems. > > > […] > Ilia Alshanetsky Best regards, Marcus --- ## #26255 — Ilia Alshanetsky — 2006-10-25T20:35:09+00:00 URL: https://externals.io/message/26214#26255 · In reply to: #26234 Thanks to Hannes we have a fairly complete list of changes in the error conditions, so far people who have commented out it did not appear to have identified anything objectionable. We need to make a decision on how to proceed, either to roll 5.2.0 now or wait another week. My vote is to roll things now... > Hello Ilia, > > both, the __toString and the iterator in foreach by reference > would put > the engine into an unstable state. That saiditis very important > that we do > not blindley change error modes here. Most changes havebeen done > for a good > reason. And most of those were added lately because we are always > pushing to > fast with releases so that we only after releasing find out whatis > causing > problems. And at that time peoplealready started to use those > 'features' > andscream if we have to remove them. Just keep this in mind - please. > > best regards > marcus > > > Tuesday, October 24, 2006, 5:13:09 PM, you wrote: > > > […] > > > > […] > > > […] > > > […] > > > > > > > > Best regards, > Marcus > > -- > > > > Ilia Alshanetsky --- ## #26300 — Christian Schneider — 2006-11-03T15:31:52+00:00 URL: https://externals.io/message/26214#26300 · In reply to: #26255 Ilia Alshanetsky wrote: > Thanks to Hannes we have a fairly complete list of changes in the error > conditions, so far people who have commented out it did not appear to > have identified anything objectionable. We need to make a decision on > how to proceed, either to roll 5.2.0 now or wait another week. My vote > is to roll things now... Out of curiosity What's the plan for `E_DEPRECATED` now? Regarding the release of PHP 5.2 and OO strictness: I never got any comment about my OO strictness patch to not complain about adding default values to parameters or changes on static methods which both do not break the quoted http://en.wikipedia.org/wiki/Liskov_substitution_principle I would have hoped for a little info why this patch was not considered. Regards, - Chris --- ## #26302 — Marcus Boerger — 2006-11-03T18:11:38+00:00 URL: https://externals.io/message/26214#26302 · In reply to: #26300 Hello Christian, Liskov applies to static methods as soon as calls via objects are common which is true for PHP. Actually in PHP static methods are inherited as any other method (also true for a lot of other languages). Now given Liskov rules you can as well add default parameter values as add new parameters with default values and even change type hints (when respecting the rules correctly). With C++ the first language has proven that changing default parameter values is a bad idea. There however mainly because they are bound at compile time based on the compile time types, which results in default values that are mostly not what you would expect. In PHP it might work as expected but then all programmers that come from langiages like C++ get confused. Also it would disallow a few optimizer things later (going the C++ way of compile time function invocatoin binding). The same holds for new additional parameters. In most languages that is no option because it would effectively be a different function. In PHP it would eventually work but add more confusion that it would help. The last point, changing type hints in derived class' methods, was discussed at PDM and declined. The main reason for that decision were that all languages we knew of do not support it and that most people even do not understand the rules which are quite the opposite of what most people think. However the point of adding `E_DEPRECATED` is still open. Where open only means which version will first have it. From my perspective that will be either 5.3.0 or 6.0.0 depending on whetever comes out first. Helping here would be greatly appreciated. best regards marcus Friday, November 3, 2006, 4:31:52 PM, you wrote: > Ilia Alshanetsky wrote: > > […] > Out of curiosity What's the plan for `E_DEPRECATED` now? > Regarding the release of PHP 5.2 and OO strictness: > I never got any comment about my OO strictness patch to not complain > about adding default values to parameters or changes on static methods > which both do not break the quoted > http://en.wikipedia.org/wiki/Liskov_substitution_principle > I would have hoped for a little info why this patch was not considered. > Regards, > - Chris Best regards, Marcus --- ## #26322 — Christian Schneider — 2006-11-04T16:13:32+00:00 URL: https://externals.io/message/26214#26322 · In reply to: #26302 Marcus Boerger wrote: > Liskov applies to static methods as soon as calls via objects are common > which is true for PHP. This is common in PHP and you consider this good practice? Interesting, wasn't what I would have expected... > Now given Liskov > rules you can as well add default parameter values as add new parameters > with default values ... > In PHP it might work as > expected but then all programmers that come from langiages like C++ get > confused. I didn't realized how big an impact C++ has on the PHP design. Allow me to *shudder*, I'm glad we're only talking `E_STRICT` here (-:C > However the point of adding `E_DEPRECATED` is still open. Where open only > means which version will first have it. From my perspective that will be > either 5.3.0 or 6.0.0 depending on whetever comes out first. Helping here > would be greatly appreciated. What help is needed, compiling the list of E_NOTICE/E_STRICT to be convert to E_DEPRECATED? Or giving input on how to convert the individual messages? I'm willing to help. Regards, - Chris --- ## #26324 — Marcus Boerger — 2006-11-04T18:05:02+00:00 URL: https://externals.io/message/26214#26324 · In reply to: #26322 Hello Christian, Saturday, November 4, 2006, 5:13:32 PM, you wrote: > Marcus Boerger wrote: > > […] > This is common in PHP and you consider this good practice? Interesting, > wasn't what I would have expected... I didn't say it is good practice, god behave :-) > > […] > I didn't realized how big an impact C++ has on the PHP design. Allow me > to *shudder*, I'm glad we're only talking `E_STRICT` here (-:C Pretty long explanation but I hope it clearifies how I was answering: Language developers copy from each other. Copy in the sense of looking at the ideas and experience from others and taking them over, in a fashion that suites their own language. As PHP has a C like syntax and also some C semantics it goes in a pool with languages like C, C++, C#, ObjC, Java and a few more. It also has influence from Perl or Delphi. Looking at the object model we have, it is a combination of influences from C++, Java and Delphi plus lately also C#. Plus stuff I cannot even specify a counterpart for, maybe some of Python. So when I mention C++ here, I am refering to a specific piece of behavior that can best be found in C++. And I would do the same for other parts with the help of other Languages. I do so becasue I consider that most people prefer an explantion by example over a theoretical explanation - in that case I can suggest nice books: - Object-Oriented Type Systems by Jens Palsberg and Michael I Schwartzbach http://www.amazon.com/Object-Oriented-Type-Systems-Jens-Palsberg/dp/047194128X/sr=1-1/qid=1162662320/ref=sr_1_1/002-5762121-6939211?ie=UTF8&s=books - A Theory of Object by Martin Abadi and Luca Cardelli http://www.amazon.com/Theory-Objects-Monographs-Computer-Science/dp/0387947752/sr=1-1/qid=1162662574/ref=sr_1_1/002-5762121-6939211?ie=UTF8&s=books Actually the first book is pretty easy and can get anybody started. The second is a pretty mathematical approach. That is very good, since it shows what you can do and what not and can explain why certain things are not working. But in PHP we don't respect much of the rules. Unless `E_STRICT` is active, which gets the most imortant ones. Luca Cardelli wrote more about the Lambda Calculus but I haven't read them since the book above captures all that's needed. > > […] > What help is needed, compiling the list of E_NOTICE/E_STRICT to be > convert to E_DEPRECATED? Or giving input on how to convert the > individual messages? I'm willing to help. Yes such a list would be very helpfull. If you think individual messages need to be altered other then changing the severity than we might need to discuss that as well. Having the list of such messages would help anyway. Because without helpfull feedback we can never get rid of design flaws. Looking forward to get that list. best regards marcus --- ## #26341 — Christian Schneider — 2006-11-05T13:05:59+00:00 URL: https://externals.io/message/26214#26341 · In reply to: #26324 Marcus Boerger wrote: > > […] > > > […] > > I didn't say it is good practice, god behave :-) So you're adding a warning to something useful (factory methods) to help people doing something dubious? ;-) > Language developers copy from each other. Copy in the sense of looking > at the ideas and experience from others and taking them over, in a > fashion that suites their own language. As PHP has a C like syntax and Just make sure you don't fall into the trap of not seeing the great potential PHP has *because* it is different from the other languages. PLEASE NOTE: I don't expect you to reply to the above points as my email is just meant as food for thought and we're discussing language design *philosophy* here which would take too much space with little hope of getting to an agreement. But that's ok, I accept your opinion and you're much more in charge of PHP than I am. > > […] > > Yes such a list would be very helpfull. If you think individual messages > need to be altered other then changing the severity than we might need to > discuss that as well. Having the list of such messages would help anyway. I don't consider the text of the messages itself as that crucial. I attached a little script which greps for error types and outputs a file to quickly visit those places in the source files. Hope this helps, - Chris --- ## #26359 — Jeff Moore — 2006-11-05T18:09:26+00:00 URL: https://externals.io/message/26214#26359 · In reply to: #26302 > Liskov applies to static methods as soon as calls via objects are > common > which is true for PHP. Actually in PHP static methods are inherited as > any > other method (also true for a lot of other languages). Now given Liskov > rules you can as well add default parameter values as add new > parameters > with default values and even change type hints (when respecting the > rules > correctly). With C++ the first language has proven that changing > default > parameter values is a bad idea. There however mainly because they are > bound > at compile time based on the compile time types, which results in > default > values that are mostly not what you would expect. In PHP it might work > as > expected but then all programmers that come from langiages like C++ get > confused. Also it would disallow a few optimizer things later (going > the C++ > way of compile time function invocatoin binding). The same holds for > new > additional parameters. In most languages that is no option because it > would > effectively be a different function. In PHP it would eventually work > but add > more confusion that it would help. The last point, changing type hints > in > derived class' methods, was discussed at PDM and declined. The main > reason > for that decision were that all languages we knew of do not support it > and > that most people even do not understand the rules which are quite the > opposite of what most people think. Hi Marcus, Enlightening explanation in a long and confusing thread. To restate the last point for clarification, if the PHP's rules were following Liskov's rules, this php -d"error_reporting=8191" -r 'class Foo {} class FooBar extends Foo {} class T {function f(FooBar $x){}} class S extends T {function f(Foo $x){}}' and possibly php -d"error_reporting=8191" -r 'class T {function f(StdClass $x){}} class S extends T {function f($x){}}' would not be `E_STRICT` violations as they currently are. In both examples the subclass weakens the parent classes' preconditions (type hints). So PHP's `E_STRICT` rules are (intentionally) 'stricter' than Liskov's rules. Best Regards, Jeff --- ## #26362 — Marcus Boerger — 2006-11-05T18:21:59+00:00 URL: https://externals.io/message/26214#26362 · In reply to: #26359 Hello Jeff, Sunday, November 5, 2006, 7:09:26 PM, you wrote: > > > […] > Hi Marcus, > Enlightening explanation in a long and confusing thread. > To restate the last point for clarification, if the PHP's rules were > following Liskov's rules, this > php -d"error_reporting=8191" -r 'class Foo {} class FooBar extends Foo > {} class T {function f(FooBar $x){}} class S extends T {function f(Foo > $x){}}' > and possibly > php -d"error_reporting=8191" -r 'class T {function f(StdClass $x){}} > class S extends T {function f($x){}}' > would not be `E_STRICT` violations as they currently are. In both > examples the subclass weakens the parent classes' preconditions (type > hints). So PHP's `E_STRICT` rules are (intentionally) 'stricter' than > Liskov's rules. Yes, both above are correct for Liskov and Lambda Calculus however it is the opposite of what most people expect. Thus we decided against it last year. So in PHP the typehint has to be as in the root class. Best regards, Marcus --- ## #26390 — Richard Lynch — 2006-11-06T20:36:21+00:00 URL: https://externals.io/message/26214#26390 · In reply to: #26302 > In PHP it might work > as > expected but then all programmers that come from langiages like C++ > get > confused. I'm sorry, but, really, I'm not interested in crippling PHP to cater to C++ converts... :-) :-) :-) I don't think this is a particularly strong point for you to make. I believe PHP stands on its own as its own merits, and forcing it to conform to some way C++ behaves, especially an artifact of the "compile" phase of C++, is just not a Good Idea. > Also it would disallow a few optimizer things later (going > the C++ > way of compile time function invocatoin binding). Just this morning I was thinking that PHP would be better off following the Lisp #. model rather than the C++ borg-like model. In Lisp, if you *want* something computed at compile-time, and you agree to it being a 'constant' after that, you can wrap it in a #. construct: #.( [expression] ) as I recall. For example: set_cookie("oatmeal", "raisin", `time()` + #.(60*60*24*365*2), '/'); #.() gives the first-pass compiler the option to compute that value immediately, substitute in the result, and use it as a CONSTANT from that point forward. Obviously we could not use #.() syntax -- That's just an example. But it could be useful in PHP for all kinds of stuff, particularly in tight loops. Of course, something as simple as: define('ME', $_SYSTEM['PHP_SELF']); define('MAX_COOKIE_TIME', 60*60*24*365*2); might be a lot easier and just as useful :-) Last time I checked, though, you couldn't do that... > In PHP it would eventually work > but add > more confusion that it would help. Really? Because I find myself more and more confused by the PHP OOP model's continued restrictions and syntax and behaviour every few months than I am by it NOT behaving like PHP. It's like I'm in some Twilight Zone where PHP is being taken over by C++/Java borg that doesn't actually like PHP as it is. [shrug] The PHP OOP model behaves less and less like PHP and more and more like all the other languages I choose *not* to use. As much as I prefer PHP 5 OOP referencing over the PHP 4 copy mess, the rest of it is quickly becoming a lot of baggage I don't really want to deal with. I've been too badly burned in the past by private/protected morass in large-scale projects from somebody else's code I can't change without all kinds of problems. Every time you guys lock something else down and force it to work your way instead of leaving it up to the Developer, I'm counting on it biting me on the butt a few years from now. That's just the way it works. :-v > However the point of adding `E_DEPRECATED` is still open. Where open > only > means which version will first have it. From my perspective that will > be > either 5.3.0 or 6.0.0 depending on whetever comes out first. Helping > here > would be greatly appreciated. I honestly belive that 6.0.0 is the Right Answer, as it will change the way too many things work from 5.2 to 5.3, as things stand now, as I understand it... -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So?