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
--
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]
