Re: Latest commit -- depreciation of call_user_method()

[Zeev Suraski <zeev@zend.com>] > One comment; Why? :) > > We've been in that discussion before. In my opinion, we should > probably rethink our whole deprecation approach. > 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). > > 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. > > 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. I second this. Although we do have some minor bloat :) here and there, I don't think we should go out of our way to break people's scripts. - Stig -- Stig Sæther Bakken <ssb@fast.no> Fast Search & Transfer ASA, Trondheim, Norway