Re: [PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] PHP-4.0.5-RC6
James,
You have to be aware that now PHP has such a big user base we need to be
very careful in the changes we make especially when we can be pretty
certain that it might burn quite a lot of people. We can break
compatibility more easily when we have a major release (as from PHP 3 to
PHP 4) but these kind of patches need to also be sensitive to the existing
users.
I personally don't know this issue very well and it is hard for me to guess
how many people will be effected. Probably some of you who know this better
can get an idea. Also I missed if this is the same directive as in php.ini.
Anyway, I'm just saying don't take the user base too lightly because most
of them aren't php-dev@ hackers who want the standards but they want their
web sites to continue working.
Anyway, this doesn't mean I am necessarily against including the patch but
we need to make sure we're all OK with it and make a decision not only
based on the standard but also on how much damage this might make.
Andi
At 09:22 PM 4/3/2001 +0100, James Moore wrote:
Yes, that's true. I did ask (couple of times) before
I committed that patch. And yes, now both and ; are
considered as arg separators.
And I'd like to think that it's a feature than bug. ;)
That would be true, if PHP would be some kind of reference
implementation. But we don't exist to force standards down
our users' throats.
It should be optional and default to off.
Why shouldnt we require people to use legal url's?
If we are conforming to standards, and I feel we should where possible (they
are there for a reason.. by your argument why should dirname("/foo/") return
/ rather than /foo, which, to most of us is the most obvious but as you
pointed out earlier the standards say so..).
If I come from some other language or where ever and expect test=1;2;3 to
work someway and it works differently to the standards "just because it does
and we dont want to ram standards down peoples throats" its going to piss me
off. I agree it should be optional but should be defaulted to on.
-James
--
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]
--
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] RE: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] PHP-4.0.5-RC6
James, You have to be aware that now PHP has such a big user base we need to be very careful in the changes we make especially when we can be pretty certain that it might burn quite a lot of people. We can break compatibility more easily when we have a major release (as from PHP 3 to PHP 4) but these kind of patches need to also be sensitive to the existing users. I personally don't know this issue very well and it is hard for me to guess how many people will be effected. Probably some of you who know this better can get an idea. Also I missed if this is the same directive as in php.ini. Anyway, I'm just saying don't take the user base too lightly because most of them aren't php-dev@ hackers who want the standards but they want their web sites to continue working. Anyway, this doesn't mean I am necessarily against including the patch but we need to make sure we're all OK with it and make a decision not only based on the standard but also on how much damage this might make. Well, I dont think any of us really know how much damage it will cause. But on the other hand we can do this for years and just say well we mustn't break backwards compatibility and we will end up with somthing looking and behaving like perl. When we have somthing as blantantly wrong as this it should be fixed. I would question about it being optional in the long term though. If we begin to make everything optional then we get to a point where PHP is so configurable with enabling this bug here or there it becomes impossible to create distribuable scipts that are easy to install and make work (making it difficult for commercial companies to create PHP Scripts to sell which is a bad thing IMHO). I propose that we have a configuration section called backwards compat that all of these go in with comments about each option then when we reach 4.1 we kill all the options and make it behave as it should. I hope that somthing as broken as this should be defaulted to on and not off (IE encourage the correct behaviour in newer scripts). -James -- 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] RE: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] PHP-4.0.5-RC6
At 09:52 PM 4/3/2001 +0100, James Moore wrote: Well, I dont think any of us really know how much damage it will cause. But on the other hand we can do this for years and just say well we mustn't break backwards compatibility and we will end up with somthing looking and behaving like perl. When we have somthing as blantantly wrong as this it should be fixed. I would question about it being optional in the long term though. If we begin to make everything optional then we get to a point where PHP is so configurable with enabling this bug here or there it becomes impossible to create distribuable scipts that are easy to install and make work (making it difficult for commercial companies to create PHP Scripts to sell which is a bad thing IMHO). I also prefer as little as possible to be configurable so that PHP applications written on one PHP installation will run on all others. I think configurability should be kept at a minimum. However, changing such behavior in a mini-version is not obvious. And when you say it's "blantantly wrong" the way it works today, well maybe it is, but we both know how many people really got bitten by this "blatantly wrong". Very few... 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]
