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
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
