Re: Latest commit -- depreciation of call_user_method()

Zeev Suraski wrote:

One comment; Why? :)

Simple, there is no point in having two functions which can do the same things. call_user_method was the less flexible of the two, so I

We've been in that discussion before. In my opinion, we should probably rethink our whole deprecation approach.

Yep, we need to decide on a standard for deprecating things.

Yes, I know that people don't like the burden of maintaining downwards compatibility. I sure as hell don't. But PHP's huge popularity boost put the development team in a position where it has *a lot* of responsibility; Doing the wrong thing will reflect badly on PHP and its acceptance as a stable solution (not segfault wise, but development wise).

Sure, yeah. But as a note, other big projects with huge user bases break compatibility as well, Perl, Apache, Python, to name three. 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...

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. (did I say this before when talking about backwards compat, AHHHHHHHHHHHHHH, hey Zeev, is PHP an OO language? ;) 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. However, you have a very good point, ISP's will be pissed if we drastically change the syntax. 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.

The only drawback I see to this approach is that the code itself remains and 'bloats' the various files. We can probably overcome this problem by separating legacy code to separate files.

or a seperate directory, backwards compat code can be placed in php4/legacy. -Sterling