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.
>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.
>>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 :)
>(did I say this before when talking about backwards compat,
>AHHHHHHHHHHHHHH, hey Zeev, is PHP an OO language? ;)
I'm not sure how it's related to downwards compatibility...
>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".
>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.
Zeev
--
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]
