Re: Latest commit -- depreciation of call_user_method()

Zeev Suraski wrote:

At 01:40 15/5/2001, Sterling Hughes wrote:

Sure, yeah. But as a note, other big projects with huge user bases break compatibility as well, Perl, Apache, Python, to name three.

It doesn't mean it's a good idea.

You no use logic on me!!! ;)

And in its own way, C, is constantly breaking compat, the amount of times I've had to upgrade programs i've written, because a library changes is countless...

Well, C's been pretty darned stable along the years, since it was ANSI'fied. C++ was a moving target. I don't recall having to make any significant changes in PHP's fairly-large codebase (as well as other codebases I was working on along the years) due to standard changes, except for, perhaps, the inline issues. I definitely wouldn't consider this to be a precedence for making downwards incompatible changes.

I'm talking about "library changes", such as a change of syntax in the expat library or the libxml library that made you change your code, its not the core of C itself, but rather the libraries surrounding it that do change.

On the other hand, I really don't like the bloat either. So, what should be done? In my opinion, the approach of adding E_NOTICE notifications to functions doesn't cut it; It won't significantly improve the situation. I think we should go in a different path (or an 'extended' path) - IMHO, the best approach would be adding some sort of a 'LEAN_AND_MEAN' mode to PHP's build. When built in this mode, bloat code will be #define'd away, or displayed as 'deprecated' in a similar manner to the way warn_not_available works. That gives everyone almost everything - people who care about the bloat (like me) will build it in LEAN_AND_MEAN mode, hosting companies or legacy sites, who care most about having their code go on working with minimum hassle - won't mind the added bloat. If kept closely documented, people who care enough about the bloat will be able to go through the checklist, make sure their sites are compatible with it, and turn this mode on.

well, you can't have your cake and eat it too.

No need to get into metaphores - I'm suggesting a very specific solution. What's the cake and who's eating it, I don't know :)

Awwwwww. Don't ruin all my fun. ;) The basic idea is this. Sometimes in order to make the language better/less bloated/easier to use. You need to break compatibility. The saying "you can't have your cake and eat it too" means simply that you can't have it both ways.

(did I say this before wh

en talking about backwards compat,

AHHHHHHHHHHHHHH, hey Zeev, is PHP an OO language? ;)

I'm not sure how it's related to downwards compatibility...

see above.

Well, what I intended to do was mark it with an E_NOTICE for this release and if no one complained with my latest commit, redo the call_user_method*() documentation as well as a big ass news entry. Next release, bump up the level to E_WARNING, and add a nice sized NEWS entry about that. Finally, third release, say buh-bye to good old call_user_method, and replace it with a new function, warn_depreciated.

Bare in mind that many people don't upgrade on every release. I'd argue even that most people don't, and only upgrade every 2 or 3 releases, that is, if they upgrade at all. So for them, this entire process will be a single and swift blow in the face, despite your efforts. Also bare in mind that a very large percentage of the developers don't *want* to be forced to change their code, and consider it to be a misfeature in the language if it breaks downwards compatibility in between releases, regardless of whether they get a clear notification about it or not.

However, you have a very good point, ISP's will be pissed if we drastically change the syntax.

They're pissed even if we slightly change the syntax, too, as a matter of fact. It's the small downwards compatibility breaks that make them say "the hell with it, I'm not upgrading".

yeah, I was unclear, I meant that, any compatibility breaking change == drastic change ;)

And your solution seems good, I'd just do the reverse (semantically speaking), so instead, what I think we should do is have a --enable-backwards-compat mode. This mode would be for ISP's and people who need the bug fixes, etc. in new PHP releases, but don't want to upgrade their scripts. So, when deprecating a feature, the following is employed: minor release 1: non backwards compat mode php_error(E_WARNING, "DEPRECATED FEATURE BUM!"); minor release 2: now the function warn_deprecated replaces the deprecated function in non backwards compat mode, backwards compat mode is the only place the function is no longer present. The function code is moved to php4/legacy.

I haven't thought out my opinion on how the deprecation process should be exactly, whether it should happen in minor or major releases only, and whether it should be on or off by default. As always, the first step would be implementing this mechanism and streamlining it. We can figure out the small details later.

I'm working on that now... Just got to nag sascha about build issues and then I'll commit something ;) -Sterling