Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
At 11:21 18/5/2001, Jani Taskinen wrote: As long as these extensions are in there, I think changing any of their API's is a justification for 4.x release. This is simply not the way we decided to work in. Can it be changed? Sure. Should it be changed? In my humble opinion, no, it shouldn't. The thing I'm trying to state, not very successfully I guess, is that whether it's 4.0.7 or 4.666.3, we should be avoiding API changes as much as at all possible. Sure, sometimes there's just no alternative than to break downwards compatibility, but we should not get into the state of mind that breaking downwards compatibility is ok, as long as you increment some digit in the version number. 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
On Fri, 18 May 2001, Zeev Suraski wrote: At 11:21 18/5/2001, Jani Taskinen wrote: As long as these extensions are in there, I think changing any of their API's is a justification for 4.x release. This is simply not the way we decided to work in. Can it be changed? Sure. Should it be changed? In my humble opinion, no, it shouldn't. The thing I'm trying to state, not very successfully I guess, is that whether it's 4.0.7 or 4.666.3, we should be avoiding API changes as much as at all possible. Sure, sometimes there's just no alternative than to break downwards compatibility, but we should not get into the state of mind that breaking downwards compatibility is ok, as long as you increment some digit in the version number. You must understand that I don't like changing the API either. But sometimes it just HAS to be changed. And one thing that should happen when such changes are made, is to change the version number. Why is it so sacred to you? I didn't suggest either that if the version number is changed it's okay to break BC.. There are now _two_ extensions that break BC. (sockets/domxml) So is it okay to break BC in extensions? And like that one user said, if we had pumped up the minor number he would have expected to see some major changes. But as long as you continue this 'this is how we have always done things' way, people WILL get pissed. Not only me. --Jani -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
At 12:05 18/5/2001, Jani Taskinen wrote: You must understand that I don't like changing the API either. But sometimes it just HAS to be changed. And one thing that should happen when such changes are made, is to change the version number. Why is it so sacred to you? Each and his own religion :) More seriously, yes, I realize that sometimes the API *HAS* to be changed. Those cases are relatively rare, and should remain as such. In cases where the main reason for 'HAVING to change' the API is code bloat (e.g. the mysql_db_query() function), I'd argue that keeping it makes much more sense, with or without version changes. I didn't suggest either that if the version number is changed it's okay to break BC.. There are now _two_ extensions that break BC. (sockets/domxml) So is it okay to break BC in extensions? And like that one user said, if we had pumped up the minor number he would have expected to see some major changes. But as long as you continue this 'this is how we have always done things' way, people WILL get pissed. Not only me. Could be. To be honest, I'm not sure what the best solution would be here. Coming out with an API that later changes is simply a bad thing, but it's all too common in PHP. IMO the problem is with the initial design, i.e., we should perhaps invest more time in designing the API to begin with, instead of just coming out with something, and later improving on it (sometimes by changing it completely). I don't mind using the middle version number to signify major changes in the API. Judging by other projects, though, people would probably expect substantial functionality improvement from such version changes, while in practice, they'd be the same. 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
On Thu, 17 May 2001, Rasmus Lerdorf wrote: I don't agree. Have you noticed the thread about domxml currently running in php-dev@? Wouldn't that justify a 4.1? What would? No, I don't think a single extension should affect the PHP version number to that extent. But I do think we should be moving towards versioning the extensions individually. Could you explain how having separate version numbers for extensions would help at all? As long as the extensions are distributed with the main PHP package, that is. There will be more and more extensions that are not bundled with PHP, and having a standard way to check the version of an extension is going to be required. This should also apply to the bundled extensions. You also have to consider that people build bundled extensions as shared extensions. For example, once upon a time I built the ftp extension as shared and I have not updated my ftp.so for quite a while even though I have updated my libphp4.so many times. So I am effectively using an old bundled extension with a new version of PHP. Right now there is no real way to detect this, and if my code used the PHP version number and determined that the API for the ftp extension is different now and tried to call the ftp functions differently then my app would break as my particular ftp extension definitely has not changed. As long as these extensions are in there, I think changing any of their API's is a justification for 4.x release. I disagree. Since optional extensions are not a core part of the language and can be built and maintained separately, changes to them should not be the main cause for bumping the major version number of PHP. Major Changes to the core of PHP or to any non-optional components should however. -Rasmus -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
On Fri, 18 May 2001, Rasmus Lerdorf wrote: As long as these extensions are in there, I think changing any of their API's is a justification for 4.x release. I disagree. Since optional extensions are not a core part of the language and can be built and maintained separately, changes to them should not be the main cause for bumping the major version number of PHP. Major Changes to the core of PHP or to any non-optional components should however. Do you really think that average PHP user makes any difference between extensions and the core? I don't think so. As long as they come in same package..it's the same for them. --Jani -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
On Fri, 18 May 2001, Jani Taskinen wrote: On Fri, 18 May 2001, Rasmus Lerdorf wrote: As long as these extensions are in there, I think changing any of their API's is a justification for 4.x release. I disagree. Since optional extensions are not a core part of the language and can be built and maintained separately, changes to them should not be the main cause for bumping the major version number of PHP. Major Changes to the core of PHP or to any non-optional components should however. Do you really think that average PHP user makes any difference between extensions and the core? I don't think so. As long as they come in same package..it's the same for them. That still doesn't change the fact that it is imprecise to tie the PHP version number to extensions when there is no 1:1 relationship here and the possibility exists that an older version of the extension can be used with a newer version of PHP. And more and more, the average PHP user does not build PHP themselves but use it on a server where PHP was built by an admin. On these servers it is getting more common for the admin to enable extensions as shared extensions from user requests which increases the likelihood of old versions of extensions sticking around and not being in synch with the PHP installation. -Rasmus -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
On Fri, 18 May 2001, Rasmus Lerdorf wrote: That still doesn't change the fact that it is imprecise to tie the PHP version number to extensions when there is no 1:1 relationship here and the possibility exists that an older version of the extension can be used with a newer version of PHP. And more and more, the average PHP user does not build PHP themselves but use it on a server where PHP was built by an admin. On these servers it is getting more common for the admin to enable extensions as shared extensions from user requests which increases the likelihood of old versions of extensions sticking around and not being in synch with the PHP installation. Hmm..I'm not really sure how it's possible to use older API version extensions with newer PHP as the Zend boys pump up their API version number on every release..and afaik that prevents you from using the old extensions..? --Jani -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
On Fri, 18 May 2001, Jani Taskinen wrote: Hmm..I'm not really sure how it's possible to use older API version extensions with newer PHP as the Zend boys pump up their API version number on every release..and afaik that prevents you from using the old extensions..? They hardly bump Zend API version with every point release. -Andrei Music expresses that which can not be said and on which it is impossible to be silent. -Victor Hugo -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
That still doesn't change the fact that it is imprecise to tie the PHP version number to extensions when there is no 1:1 relationship here and the possibility exists that an older version of the extension can be used with a newer version of PHP. And more and more, the average PHP user does not build PHP themselves but use it on a server where PHP was built by an admin. On these servers it is getting more common for the admin to enable extensions as shared extensions from user requests which increases the likelihood of old versions of extensions sticking around and not being in synch with the PHP installation. Hmm..I'm not really sure how it's possible to use older API version extensions with newer PHP as the Zend boys pump up their API version number on every release..and afaik that prevents you from using the old extensions..? ZEND_MODULE_API_NO last changed in December of last year. If you look through CVS you will find that there have been many releases without a change in ZEND_MODULE_API_NO. Right now an extension built 5 months ago still loads perfectly into a current snapshot. -Rasmus -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
On Fri, 18 May 2001, Rasmus Lerdorf wrote: That still doesn't change the fact that it is imprecise to tie the PHP version number to extensions when there is no 1:1 relationship here and the possibility exists that an older version of the extension can be used with a newer version of PHP. And more and more, the average PHP user does not build PHP themselves but use it on a server where PHP was built by an admin. On these servers it is getting more common for the admin to enable extensions as shared extensions from user requests which increases the likelihood of old versions of extensions sticking around and not being in synch with the PHP installation. Hmm..I'm not really sure how it's possible to use older API version extensions with newer PHP as the Zend boys pump up their API version number on every release..and afaik that prevents you from using the old extensions..? ZEND_MODULE_API_NO last changed in December of last year. If you look through CVS you will find that there have been many releases without a change in ZEND_MODULE_API_NO. Right now an extension built 5 months ago still loads perfectly into a current snapshot. Ah. I must have been dreaming then.. :) I remember that someone submitted some bug report about this very issue. Anyway, now I see that there really is good reason having that version (PHP_#ext#_API_NO ?) after all. And having that..we should propable start moving those extensions one by one into PEAR? Maybe we could then roll out two packages, one for core and one for the extensions? And btw. Why not have a function in PHP core that can be used to get the desired extensions remotely from pear.php.net? If we have a PHP_#ext#_API_NO, running a 'update_php_extensions()' would go and grab the updated (if the extension HAS been updated) one..etc.. (I'm just thinking out loud..ignore me :) --Jani -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
Rasmus Lerdorf wrote: [...] which increases the likelihood of old versions of extensions sticking around and not being in synch with the PHP installation. not to likely nowadays due to the API number changes that made binary extensions not being loaded by other php versions then the ones they were compiled for (with the only exception of php 4.0.2 and 4.0.3 which had no api changes between releases) but as the api was said to be most likely stable now this will be an upcomming problem again in the (near?) future -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
Andrei Zmievski wrote: They hardly bump Zend API version with every point release. not with every release, somehow they missed 4.0.3 on this ;) -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
Ah. I must have been dreaming then.. :) I remember that someone submitted some bug report about this very issue. Anyway, now I see that there really is good reason having that version (PHP_#ext#_API_NO ?) after all. And having that..we should propable start moving those extensions one by one into PEAR? That has been the plan for a while now. Not necessarily moving all the optional extensions, but some of them. And new fringe extensions would go straight to PEAR. And btw. Why not have a function in PHP core that can be used to get the desired extensions remotely from pear.php.net? If we have a PHP_#ext#_API_NO, running a 'update_php_extensions()' would go and grab the updated (if the extension HAS been updated) one..etc.. (I'm just thinking out loud..ignore me :) There is the start of a set of command line tools for doing this. -Rasmus -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
Andrei Zmievski wrote: They hardly bump Zend API version with every point release. not with every release, somehow they missed 4.0.3 on this ;) No bump in 4.0.6 either, and it doesn't look like there will be one for 4.0.7 either. About 5 months since the last bump. -Rasmus -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
Jani Taskinen wrote: Anyway, now I see that there really is good reason having that version (PHP_#ext#_API_NO ?) after all. And having that..we should propable start moving those extensions one by one into PEAR? do we have the infrastructure in PEAR for C code yet ? Maybe we could then roll out two packages, one for core and one for the extensions? this wouldn't really solve the problem as you still have different versions of packages at least in the extension part while it adds more complexity leading to users trying to get core version x together with extensions version y where x and y do not fit And btw. Why not have a function in PHP core that can be used to get the desired extensions remotely from pear.php.net? If we have a PHP_#ext#_API_NO, running a 'update_php_extensions()' would go and grab the updated (if the extension HAS been updated) one..etc.. nice idea, but once again: we are talking about C-code and shared libraries here, how do you get a system to compile things automaticly from within a webserver process (which usually does not have the access rights needed to update things in the filesystem) and how do you force php to exchange .so versions on the fly, especially in a multi- threaded server, while keeping php and the server running ? -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
Jani Taskinen wrote: Anyway, now I see that there really is good reason having that version (PHP_#ext#_API_NO ?) after all. And having that..we should propable start moving those extensions one by one into PEAR? do we have the infrastructure in PEAR for C code yet ? Not yet, so this isn't something that is going to happen tomorrow. And we also have to be very careful about how it is done. One of the big strengths of PHP is that you don't generally have to run around looking for the right versions of extensions to match a certain version of PHP. It just works. -Rasmus -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
On Fri, 18 May 2001, Rasmus Lerdorf wrote: Ah. I must have been dreaming then.. :) I remember that someone submitted some bug report about this very issue. Anyway, now I see that there really is good reason having that version (PHP_#ext#_API_NO ?) after all. And having that..we should propable start moving those extensions one by one into PEAR? That has been the plan for a while now. Not necessarily moving all the optional extensions, but some of them. And new fringe extensions would go straight to PEAR. Too bad it seems not to be going anywhere.. And btw. Why not have a function in PHP core that can be used to get the desired extensions remotely from pear.php.net? If we have a PHP_#ext#_API_NO, running a 'update_php_extensions()' would go and grab the updated (if the extension HAS been updated) one..etc.. (I'm just thinking out loud..ignore me :) There is the start of a set of command line tools for doing this. I don't think having those separately is a good idea. More like a function set in PHP would make more sense. As you have to have the core PHP anyway? --Jani -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
And btw. Why not have a function in PHP core that can be used to get the desired extensions remotely from pear.php.net? If we have a PHP_#ext#_API_NO, running a 'update_php_extensions()' would go and grab the updated (if the extension HAS been updated) one..etc.. (I'm just thinking out loud..ignore me :) There is the start of a set of command line tools for doing this. I don't think having those separately is a good idea. More like a function set in PHP would make more sense. As you have to have the core PHP anyway? I don't see how that would work. The command-line tool would pull down the tarball, phpize it to pull in the local configuration settings, then build the extension. Doing all this from an internal PHP call doesn't make any sense to me. That's like saying that phpize should be an internal PHP function instead of the current shell script that it is now. -Rasmus -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
Rasmus Lerdorf wrote: There will be more and more extensions that are not bundled with PHP, and having a standard way to check the version of an extension is going to be required. This should also apply to the bundled extensions. Currently there is a number of self-description functions in PHP, such as the name of the current SAPI, tests for existing (loaded) extensions and similar. I'd second your request for a function or a number of functions that report properties of a loaded extension, and I'd like to see section in a manual that deals with analyzing your PHP environment from a program. So 1. how would I get a list of all currently loaded modules and their version number? 2. how would I get a list of functions names, constants and magic variables and internal objects created by this module? 3. what information can I get about the PHP core (version, SAPI, other information). Question is, would it be possible write phpinfo() as a user function? If yes, the set of self description of PHP would be fairly complete - the list of function names etc actually transcends phpino(). This could be interpreted as a shortcoming of phpinfo(): module names should be clickable in phpinfo() and lead to a page describing that module in detail. Kristian -- Kristian Köhntopp, NetUSE AG Dr.-Hell-Straße, D-24107 Kiel Tel: +49 431 386 435 00, Fax: +49 431 386 435 99 -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
[Jani Taskinen [EMAIL PROTECTED]] On Thu, 17 May 2001, Rasmus Lerdorf wrote: I don't agree. Have you noticed the thread about domxml currently running in php-dev@? Wouldn't that justify a 4.1? What would? No, I don't think a single extension should affect the PHP version number to that extent. But I do think we should be moving towards versioning the extensions individually. Could you explain how having separate version numbers for extensions would help at all? As long as the extensions are distributed with the main PHP package, that is. It doesn't help of course. As long as these extensions are in there, I think changing any of their API's is a justification for 4.x release. Again, this is how it's always been done. A single extension has never caused a minor version bump, and I don't see it happening (the only extension I could see remotely justifying that would be ext/standard, which is part of the core anyway...) It is becoming painfully obvious what kind of release nightmare PHP is cornering itself into. The only way out of this mess is to split PHP into smaller projects with their own release cycles, which is what I wanted to do with 4.1 in the first place. Until we do that, we're stuck with our Cathedral, and will continue having RC/QA periods of at least four weeks on micro releases. So MNSHO is that 4.1 should be the split, and nothing but. We can release 4.2 just a couple of months after to address the other things people have signed up for 4.1 now. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
One thing I'd like to see is a utility which could check a source directory and warn about obviously deprecated / insecure / inefficient things. It'd make life easier for that hypothetical ISP admin with a large pile of code which has been haphazardly maintained for years. hey, guys, how do you imagine an isp admin changing hosted code in order to upgrade php to a newer incompatible version? this is a dream - if isps are not sure it will work without changes, they will never upgrade. if they upgrade and thousands of sites stop working many people will _really_hate_ php lets say i am the client and my isp decides to upgrade - they change my .php files so they now work with the latest php version, tommorow i login and upload my newer version and everything stops working, yes everything because one of the files included everywhere uses a deprecated construct and bloats with a syntax error... breaking backward compatibility in php is not a good thing - it even cannot be compared to apache 1.2.x differences to 1.3.x ones. for isps the webserver is their responsibility but php code is user's. moving from apache 1.2.x to 1.3.x for a server with hundreds of hosted sites is a piece of cake compared to upgrading from php3 to php4 - this is the reason many isps do not upgrade and will not b. -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
On Wed, 16 May 2001, Rasmus Lerdorf wrote: Sure, but a version number if quite arbitrary and the way we have always ^^ Exactly.. done this is to consider the second digit for large changes. The fact that we haven't had a .1 yet is not really relevant. I don't see why you are making such a big deal out of a version number. ..why can't this 'way we have always' be changed to something else..? :) I'm making this a 'big deal' because it really is time to make some changes in 'the way we have always done things' as it seems to only prevent us from doing anything else.. What I meant with this version number thingie is that as e.g. Zeev doesn't like breaking the 'backwards compatibility' (referred to as BC from now on) we have to find a way to do it 'nicely'. Why not have some kind of roadmap for these. ie. say in that in which versions (minor number) will some function,extension, etc. not exist, or in which version something isn't BC anymore. And like Sean suggested, we could create some tools which either fix or at least inform that the script is not gonna work with 4.x.x version. [EMAIL PROTECTED] is just for administrative purposes. Licensing issues and Ok. I had totally wrong idea of it then. Sorry. --Jani -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
On 16 May 2001, Stig Sæther Bakken wrote: Hey Jani, you can attribute yourself as the PHP Whipping Boy now if you like. I think you just got enough points. :-) Ok. :) I completely agree that we should start using the minor version. It's like we're afraid to touch it because that would imply too big changes or something. Seeing how huge our process between micro versions has become, it's just getting weirder. My thoughts exactly. It should be made clear in some place, that when the minor number changes, what it means. I think we should take a good look at the 4.1 TODO and split into a 4.1 and 4.2 TODO, and have 4.1 out sooner, maybe even as the next release after 4.0.6. Yes, please. :) --Jani -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
On Wed, 16 May 2001, Andrei Zmievski wrote: Being antagonistically sarcastic won't win you any friends, Jani. If I wanted friends, I'd get a dog.. :) As far as your question about the version numbers, the middle digit gets bumped up when we plan some changes that will break backwards compatibility and implement features in the core language. So, yes, it is something special, it's not for bug fixes or extension changes. Exactly. As we now agree with it, let's get busy and start breaking things! :) --Jani -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
As far as your question about the version numbers, the middle digit gets bumped up when we plan some changes that will break backwards compatibility and implement features in the core language. So, yes, it is something special, it's not for bug fixes or extension changes. Exactly. As we now agree with it, let's get busy and start breaking things! :) dont know if that is a good idea =) i dont see the problems by breaking in other projects, but if you break it in a language like php, weve got the problem that a lot of scrips will not work any longer.. if you break in c / perl / etc. thats no prob, afaik you just need to compile your work before you update the language. In PHP you cant, if you upgrade your scripts need to work if not, providers would need to run more than one php version.. this would give a chaos like index.php4.0 index.php4.1 index.php4.2 etc... this cant be the right way... -- Peter -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
Being antagonistically sarcastic won't win you any friends, Jani. If I wanted friends, I'd get a dog.. :) As far as your question about the version numbers, the middle digit gets bumped up when we plan some changes that will break backwards compatibility and implement features in the core language. So, yes, it is something special, it's not for bug fixes or extension changes. Exactly. As we now agree with it, let's get busy and start breaking things! :) I really don't think that this should be something to strive for. There should be a really really good reason for making changes that break backward compatibility. We have that second version number reserved for such BC breaking changes that don't involve a huge rewrite (which is what the first version number is for). And yes, we have been very afraid to make such changes, as we should be! And the fact that we have never had a .1 is an indication of just how unwilling we have been to make such changes. I see this as a success and not as a failure. Imagine writing a PHP package and having to indicate that this package will work on PHP 4.0.x, not 4.1.x and 4.2.x, but 4.3.x is fine. But, if a good case can be made for such changes, or if we have a large set of feature changes, then sure, let's use that second version number. It isn't a rule written instone that the second version number is exclusively for BC-breaking changes. That's just what we have done so far. -Rasmus -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
At 06:56 17.5. 2001 -0700, [EMAIL PROTECTED] wrote: Being antagonistically sarcastic won't win you any friends, Jani. If I wanted friends, I'd get a dog.. :) As far as your question about the version numbers, the middle digit gets bumped up when we plan some changes that will break backwards compatibility and implement features in the core language. So, yes, it is something special, it's not for bug fixes or extension changes. Exactly. As we now agree with it, let's get busy and start breaking things! :) I really don't think that this should be something to strive for. There should be a really really good reason for making changes that break backward compatibility. We have that second version number reserved for such BC breaking changes that don't involve a huge rewrite (which is what the first version number is for). And yes, we have been very afraid to make such changes, as we should be! And the fact that we have never had a .1 is an indication of just how unwilling we have been to make such changes. I see this as a success and not as a failure. Imagine writing a I don't agree. Have you noticed the thread about domxml currently running in php-dev@? Wouldn't that justify a 4.1? What would? PHP package and having to indicate that this package will work on PHP 4.0.x, not 4.1.x and 4.2.x, but 4.3.x is fine. But, if a good case can be made for such changes, or if we have a large set of feature changes, then sure, let's use that second version number. It isn't a rule written instone that the second version number is exclusively for BC-breaking changes. That's just what we have done so far. -Rasmus -- 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] [EMAIL PROTECTED] - And the eyes of them both were opened and they saw that their files were world readable and writable, so they chmoded 600 their files. - Book of Installation chapt 3 sec 7 -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
I really don't think that this should be something to strive for. There should be a really really good reason for making changes that break backward compatibility. We have that second version number reserved for such BC breaking changes that don't involve a huge rewrite (which is what the first version number is for). And yes, we have been very afraid to make such changes, as we should be! And the fact that we have never had a .1 is an indication of just how unwilling we have been to make such changes. I see this as a success and not as a failure. Imagine writing a I don't agree. Have you noticed the thread about domxml currently running in php-dev@? Wouldn't that justify a 4.1? What would? No, I don't think a single extension should affect the PHP version number to that extent. But I do think we should be moving towards versioning the extensions individually. -Rasmus -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
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, AHH, 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
On Wed, 16 May 2001, Zeev Suraski wrote: 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 Who's forcing anybody to update anyway? misfeature in the language if it breaks downwards compatibility in between releases, regardless of whether they get a clear notification about it or not. It seems like everybody just ignores my emails..oh well. So I can rant again. :-p Have you ever heard that you can also change that number in the middle? 4.0.6 This one^ It can be something else than an ellipse called zero..it can even be a number 1!!! Whoa! Never thougth about that?! And maybe, just MAYBE then these people (who you seem to think of as complete idiots) would READ the NEWS file? Or e.g. RELEASE_NOTES ? Or is that number in the middle reserved for something special? Something the 'group' only know of and don't want to tell us lower class people? Maybe the 'group' could take their thumbs out of their asses and start DOING something? And maybe they could start listening to new ideas for once and a while. Or is the 'group' nowadays only Zeev/Andi ? It would be really nice to hear from the other members of the 'group' also as it really seems like the only ones speaking for it are Zeev/Andi.. Or could someone please define the function of this mysterious 'group' ? (And please, someone else than Zeev/Andi.. :) --Jani -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
On Wed, 16 May 2001, Jani Taskinen wrote: Have you ever heard that you can also change that number in the middle? 4.0.6 This one^ It can be something else than an ellipse called zero..it can even be a number 1!!! Whoa! Never thougth about that?! And maybe, just MAYBE then these people (who you seem to think of as complete idiots) would READ the NEWS file? Or e.g. RELEASE_NOTES ? Or is that number in the middle reserved for something special? Something the 'group' only know of and don't want to tell us lower class people? Maybe the 'group' could take their thumbs out of their asses and start DOING something? And maybe they could start listening to new ideas for once and a while. Or is the 'group' nowadays only Zeev/Andi ? It would be really nice to hear from the other members of the 'group' also as it really seems like the only ones speaking for it are Zeev/Andi.. Or could someone please define the function of this mysterious 'group' ? (And please, someone else than Zeev/Andi.. :) Being antagonistically sarcastic won't win you any friends, Jani. As far as your question about the version numbers, the middle digit gets bumped up when we plan some changes that will break backwards compatibility and implement features in the core language. So, yes, it is something special, it's not for bug fixes or extension changes. -Andrei Politics is for the moment, an equation is for eternity. -- Albert Einstein -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
At 14:06 16/5/2001, Jani Taskinen wrote: On Wed, 16 May 2001, Zeev Suraski wrote: 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 Who's forcing anybody to update anyway? We are, by not supporting old versions (i.e., no bug fixes, no security updates, no nothing). misfeature in the language if it breaks downwards compatibility in between releases, regardless of whether they get a clear notification about it or not. It seems like everybody just ignores my emails..oh well. So I can rant again. :-p I don't ignore your Email; I answered you. Have you ever heard that you can also change that number in the middle? 4.0.6 This one^ It can be something else than an ellipse called zero..it can even be a number 1!!! Whoa! Never thougth about that?! So what? ISPs and many companies won't be bothered even if you change the ellipse to the number of the beast. So what. It breaks compatibility. And maybe, just MAYBE then these people (who you seem to think of as complete idiots) would READ the NEWS file? Or e.g. RELEASE_NOTES ? It has nothing to do with their level of stupidity, or even ignorance. They can be Einsteins, but breaking downwards compatibility means we're giving them work to do, work that they don't want to do, and shouldn't be forced to do. Or is that number in the middle reserved for something special? Something the 'group' only know of and don't want to tell us lower class people? Maybe the 'group' could take their thumbs out of their asses and start DOING something? And maybe they could start listening to new ideas for once and a while. Or is the 'group' nowadays only Zeev/Andi ? It would be really nice to hear from the other members of the 'group' also as it really seems like the only ones speaking for it are Zeev/Andi.. Or could someone please define the function of this mysterious 'group' ? (And please, someone else than Zeev/Andi.. :) I'll let that topic slide for now. We'll get around to it soon. At any rate, other than your mood, the issue of the group has nothing to do with this issue. 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
Hi Andrei. Yes, that's how it should be, but not how it is. At least I've been observing PHP 4.0.x evolve dramatically with compat breakage included. At 08:34 16.5. 2001 -0500, Andrei Zmievski wrote: As far as your question about the version numbers, the middle digit gets bumped up when we plan some changes that will break backwards compatibility and implement features in the core language. So, yes, it is something special, it's not for bug fixes or extension changes. -Andrei [EMAIL PROTECTED] - And the eyes of them both were opened and they saw that their files were world readable and writable, so they chmoded 600 their files. - Book of Installation chapt 3 sec 7 -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
new way: call_user_func(array($obj, method), method, args, go, here); ---^ isn't 'pass by reference' deprecated too ? harald. -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
Harald Radi wrote: new way: call_user_func(array($obj, method), method, args, go, here); ---^ isn't 'pass by reference' deprecated too ? yes, so? the above is not pass by reference, your passing an array to the function, not a reference to an array. -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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
At 01:06 PM 5/16/2001 +0200, Jani Taskinen wrote: On Wed, 16 May 2001, Zeev Suraski wrote: 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 Who's forcing anybody to update anyway? misfeature in the language if it breaks downwards compatibility in between releases, regardless of whether they get a clear notification about it or not. It seems like everybody just ignores my emails..oh well. So I can rant again. :-p Have you ever heard that you can also change that number in the middle? 4.0.6 This one^ It can be something else than an ellipse called zero..it can even be a number 1!!! Whoa! Never thougth about that?! And maybe, just MAYBE then these people (who you seem to think of as complete idiots) would READ the NEWS file? Or e.g. RELEASE_NOTES ? Or is that number in the middle reserved for something special? Something the 'group' only know of and don't want to tell us lower class people? Maybe the 'group' could take their thumbs out of their asses and start DOING something? And maybe they could start listening to new ideas for once and a while. Or is the 'group' nowadays only Zeev/Andi ? It would be really nice to hear from the other members of the 'group' also as it really seems like the only ones speaking for it are Zeev/Andi.. Or could someone please define the function of this mysterious 'group' ? (And please, someone else than Zeev/Andi.. :) I hope you don't mind me replying :) I agree with you that we can bump the second version number. I think the biggest question is if we were to create a 4.1.x in order to make changes (not features necessarily) which we think are important for standardization of function names, install paths and so on then how do we do it. There has been lots of talk and I think there have also been some good ideas. The only problem I have had with these discussions up to now is that people here really forget that the average PHP coder is not a php-dev guy who wants everything to be perfect. So we can maybe start making a plan for 4.1.x which would address this standardization but I would definitely urge to think of the average PHP user and give him an option which 95% of the time won't trash his site :) Andi -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
[Zeev Suraski [EMAIL PROTECTED]] 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 [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
[Jani Taskinen [EMAIL PROTECTED]] On Wed, 16 May 2001, Zeev Suraski wrote: 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 Who's forcing anybody to update anyway? misfeature in the language if it breaks downwards compatibility in between releases, regardless of whether they get a clear notification about it or not. It seems like everybody just ignores my emails..oh well. So I can rant again. :-p Have you ever heard that you can also change that number in the middle? 4.0.6 This one^ It can be something else than an ellipse called zero..it can even be a number 1!!! Whoa! Never thougth about that?! And maybe, just MAYBE then these people (who you seem to think of as complete idiots) would READ the NEWS file? Or e.g. RELEASE_NOTES ? Or is that number in the middle reserved for something special? Something the 'group' only know of and don't want to tell us lower class people? Maybe the 'group' could take their thumbs out of their asses and start DOING something? And maybe they could start listening to new ideas for once and a while. Or is the 'group' nowadays only Zeev/Andi ? It would be really nice to hear from the other members of the 'group' also as it really seems like the only ones speaking for it are Zeev/Andi.. Or could someone please define the function of this mysterious 'group' ? (And please, someone else than Zeev/Andi.. :) Hey Jani, you can attribute yourself as the PHP Whipping Boy now if you like. I think you just got enough points. :-) I completely agree that we should start using the minor version. It's like we're afraid to touch it because that would imply too big changes or something. Seeing how huge our process between micro versions has become, it's just getting weirder. I think we should take a good look at the 4.1 TODO and split into a 4.1 and 4.2 TODO, and have 4.1 out sooner, maybe even as the next release after 4.0.6. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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]
RE: [PHP-DEV] Latest commit -- depreciation of call_user_method()
-Original Message- From: Andi Gutmans [mailto:[EMAIL PROTECTED]] ... There has been lots of talk and I think there have also been some good ideas. The only problem I have had with these discussions up to now is that people here really forget that the average PHP coder is not a php-dev guy who wants everything to be perfect. So we can maybe start making a plan for 4.1.x which would address this standardization but I would definitely urge to think of the average PHP user and give him an option which 95% of the time won't trash his site :) Andi Its not really my place to throw in my $0.02 having only contributed very little thus far to the project, but reading this gave me a thought. Why not create a utility program before compatibility breaking releases that runs through existing scripts and reports to the user/developer what types of changes need to be made in order for the script to work properly under a new version? This way a user could download and build the utility, run it, receive a report of the deprecated/changed functions, determine the amount of effort that is going to be required to update his/her scripts and then make an decision as when/if to upgrade. It could feed off of some sort of database on php.net so that we can update it with each new version without having the user download/build again. It may sound like a silly idea, but there needs to be some sort of migration plan, and at least this way we will not be alienating the end-users. Sean -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
At 08:31 PM 5/16/2001 -0400, Stig Sæther Bakken wrote: [Jani Taskinen [EMAIL PROTECTED]] On Wed, 16 May 2001, Zeev Suraski wrote: 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 Who's forcing anybody to update anyway? misfeature in the language if it breaks downwards compatibility in between releases, regardless of whether they get a clear notification about it or not. It seems like everybody just ignores my emails..oh well. So I can rant again. :-p Have you ever heard that you can also change that number in the middle? 4.0.6 This one^ It can be something else than an ellipse called zero..it can even be a number 1!!! Whoa! Never thougth about that?! And maybe, just MAYBE then these people (who you seem to think of as complete idiots) would READ the NEWS file? Or e.g. RELEASE_NOTES ? Or is that number in the middle reserved for something special? Something the 'group' only know of and don't want to tell us lower class people? Maybe the 'group' could take their thumbs out of their asses and start DOING something? And maybe they could start listening to new ideas for once and a while. Or is the 'group' nowadays only Zeev/Andi ? It would be really nice to hear from the other members of the 'group' also as it really seems like the only ones speaking for it are Zeev/Andi.. Or could someone please define the function of this mysterious 'group' ? (And please, someone else than Zeev/Andi.. :) Hey Jani, you can attribute yourself as the PHP Whipping Boy now if you like. I think you just got enough points. :-) I completely agree that we should start using the minor version. It's like we're afraid to touch it because that would imply too big changes or something. Seeing how huge our process between micro versions has become, it's just getting weirder. I think we should take a good look at the 4.1 TODO and split into a 4.1 and 4.2 TODO, and have 4.1 out sooner, maybe even as the next release after 4.0.6. I agree. I just think we should concentrate on something specific for 4.1. Otherwise, we're going to split up our efforts too much and 4.1 won't happen. I would go with the standardization stuff everyone has wanted and get it over with :) I'd like to do this without breaking everyone's sites though. Andi -- 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]
RE: [PHP-DEV] Latest commit -- depreciation of call_user_method()
At 10:27 PM 5/16/2001 -0400, Sean R. Bright wrote: -Original Message- From: Andi Gutmans [mailto:[EMAIL PROTECTED]] ... There has been lots of talk and I think there have also been some good ideas. The only problem I have had with these discussions up to now is that people here really forget that the average PHP coder is not a php-dev guy who wants everything to be perfect. So we can maybe start making a plan for 4.1.x which would address this standardization but I would definitely urge to think of the average PHP user and give him an option which 95% of the time won't trash his site :) Andi Its not really my place to throw in my $0.02 having only contributed very little thus far to the project, but reading this gave me a thought. Why not create a utility program before compatibility breaking releases that runs through existing scripts and reports to the user/developer what types of changes need to be made in order for the script to work properly under a new version? This way a user could download and build the utility, run it, receive a report of the deprecated/changed functions, determine the amount of effort that is going to be required to update his/her scripts and then make an decision as when/if to upgrade. It could feed off of some sort of database on php.net so that we can update it with each new version without having the user download/build again. It may sound like a silly idea, but there needs to be some sort of migration plan, and at least this way we will not be alienating the end-users. I think these kind of utilities are in general a good idea. We created one for the PHP/FI 2 - PHP 3 transition which helped people quite a bit. Andi -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
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. Zeev At 22:28 14/5/2001, Sterling Hughes wrote: howdy, Just sending a note about the deprecation of the call_user_method() functions. It basically sends an E_NOTICE message now when call_user_method() or call_user_method_array() are called. This is because the call_user_method() and call_user_method_array() functions can easily be duplicated by: old way: call_user_method($func, $obj, method, args, go, here); new way: call_user_func(array($obj, method), method, args, go, here); Comments? Questions? -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] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- 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]
Re: [PHP-DEV] 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, AHH, 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
On 14 May 2001 15:37:43 -0700, Sterling Hughes [EMAIL PROTECTED] wrote: 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. One thing I'd like to see is a utility which could check a source directory and warn about obviously deprecated / insecure / inefficient things. It'd make life easier for that hypothetical ISP admin with a large pile of code which has been haphazardly maintained for years. -- 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]
