I really would like have consistency and new error levels as I proposed.
It may not be a good idea for 4.2.0, but I think it is good for 4.3.0 or
5.0, if we annouce it early enough.
E_ERROR: Fatal error.
E_WARNING: Bug in script. Runtime error should not be ignored.
E_NOTICE: Possible bug in script. Runtime error can be ignored.
E_DEBUG: Error messages useful for debugging. Errors safe to ignore.
E_INFO: Not really a error but just a info. Useful for API change
notice, etc.
There are only 2300 php_error/zend_error in current source ;)
--
Yasuo Ohgaki
[EMAIL PROTECTED] wrote:
> ID: 14538
> Updated by: mfischer
> Reported By: [EMAIL PROTECTED]
> Old Status: Closed
> Status: Open
> Old Bug Type: Unknown/Other Function
> Bug Type: Documentation problem
> Operating System: Any
> PHP Version: 4.1.0
> New Comment:
>
> Reclassifying as a documentation problem (and reopened).
>
> Manuel did a good job tracking down when the behaviour of dirname() has changed and
>it won't hurt us putting this information into the documentation.
>
> Previous Comments:
> ------------------------------------------------------------------------
>
> [2001-12-15 20:19:58] [EMAIL PROTECTED]
>
> Daniel,
>
> I don't think you are realizing how serious this is!
>
> dirname was added to PHP 3.0a3 which was released more than 4 years ago. Until a
>year ago it had a behaviour that Andi thought it was not correct, so he fixed it for
>PHP 4.0.3 eventually breaking the code of people that did not realize it then because
>they don't upgrade PHP on every minor release.
>
> So, the point is that what he thought was just a fix, was rather a behaviour change
>but he really didn't realize it until I reported today.
>
> I am not proposing a php.ini option. What I am saying is:
>
> 1) Admit that Andi did not make a wise decision then and so avoid any future
>decisions like this.
>
> 2) Decisions like this break end users code and prevents them from upgrading.
>
> 3) Everytime a developer faces a decision like this, always provide a backwards
>compatible solution to not cause harm to people code base and not hurt their
>applications or even their businesses.
>
> I think PHP developers were wise enough to avoid backwards compatibily problems of
>registering global by having a php.ini switch. I don't see why that could be bad for
>dirname. I am not even saying that you should always add a php.ini switch, but at
>least is a solution that does not leave people out there in the cold.
>
>
> ------------------------------------------------------------------------
>
> [2001-12-15 19:50:54] [EMAIL PROTECTED]
>
> Actually, you both (Zeev and Manuel) are demanding the same thing, in case you
>didn't recognize. You both want a high backwards compatibility, but whereas Manuel is
>proposing a switch in php.ini for every little thing, Zeev rather prefers to have
>this compatibility "out of the box" (i.e. every script should run with the same
>behaviour on every PHP installation - which isn't 100% possible, what he accepts).
>
> providing seperate switches for every little thing would extremely complexify PHP
>programming, as you have to take care of every additional switch in PHP, therefore I
>agree with Zeev. The best thing would be to never change a language behaviour, but
>sometimes it seems to be unavoidable.
>
> ------------------------------------------------------------------------
>
> [2001-12-15 19:06:47] [EMAIL PROTECTED]
>
> Zeev,
>
> As always I am trying to be constructive here.
>
> I am trying to bring the attention to the fact that as in the past, many ISPs did
>not upgrade from old PHP versions because they have bad experiences of having their
>clients code broken in new PHP versions. In this case, an old PHP version is 4.0.0
>which is the previous major version.
>
> If you decide to not be sensitive to this point , I am afraid you will be leaving a
>lot of people annoyed and loosing business.
>
> As to the eventual accusation of being unprofessional, I mean that I am afraid that
>it will be what other people will think about who made these backward incompatible
>changes.
>
> Forget that I am the person reporting here. I am not relying on that you ever make a
>wise decision regarding this. I'll have to make my code work similarly to what you
>suggested because I am well aware of the problem, but I am afraid that most people
>isn't.
>
> I was just trying to help you avoid any future problems of credibility and
>professionalism before other people that may arise from these backward incompatible
>incidents (I am afraid there are more issues than just dirname).
>
> I am just trying to help here, I regret the fact that my report is just being
>discarded as if I never made it to help you release PHP with a more professional
>attitude. Anyway, I am used to this systematic "ignore Manuel Lemos" atitude of
>yours. So, do whatever you think is best for your business and keep not caring about
>me spending time to help you. :-(
>
> ------------------------------------------------------------------------
>
> [2001-12-15 18:47:57] [EMAIL PROTECTED]
>
> Manuel,
>
> This behavior is not going to change, and we're not going to introduce a new
>headache-causing INI option to toggle this behavior.
>
> If you really can't fix the code, you can create my_dirname() that wraps around
>dirname, and returns "" if the result is "". Then, all you have to do is a
>search&replace of dirname -> my_dirname.
>
> You use this 'threat' of being accused in unprofessionalism a bit too often, in my
>humble opinion :)
>
>
> ------------------------------------------------------------------------
>
> [2001-12-15 18:41:16] [EMAIL PROTECTED]
>
> I was trying to test PHP 4.1.0 in a production site that I have that is made of
>large code base and realized that dirname original behaviour was broken severely.
>
> The site exists for more than 2 years and always relied on the behaviour that
>dirname("/index.php") would return "" as it has been since PHP 3.
>
> The site has 4.0.0 and was never upgraded since because I have this policy of not
>installing minor versions to avoid spending a lot of time maintaining changes that
>are caused by bugs that may have been introduced.
>
> I investigated and it seems that in PHP 4.0.3, Andi fixed dirname so that
>dirname("/index.php") now returns "/" instead of "" as before.
>
> Although this should have been probably the original behaviour of the function, the
>fact is that it wasn't not even in PHP 3 days.
>
> My site heavily relies on this feature to let scripts realize in which directory
>they are relatively to the server document root using dirname(GetEnv("SCRIPT_NAME"))
>. So, my site is seriously broken because I use this everywhere in the site.
>
> I talked with Andi and he is not willing to restore the original behaviour because
>the fix was done more than 1 year ago.
>
> So, I propose that some option be added to php.ini that lets developers restore the
>original behaviour so that their sites don't break because of this change.
>
> I also would like to recommend PHP developers to take more care when making these
>changes that break the existing PHP code base of PHP users because many ISP are
>refusing to upgrade to more recent versions because it breaks their clients PHP code
>and they would be loosing business if they would upgrade to a newer version.
>
> Please consider this proposal carefully to avoid being accused of unprofessionalism
>of not assuring backwards compatibility of PHP functions behaviour.
>
> ------------------------------------------------------------------------
>
>
>
> Edit this bug report at http://bugs.php.net/?id=14538&edit=1
>
>
--
Yasuo Ohgaki
--
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]
