phpbar.de logo

Mailinglisten-Archive

[php] number_format

[php] number_format

J Westhoff j at cmail.de
Mon Jun 14 16:42:38 CEST 2004


Hi,

> Bevor man eine neue PHP-Version einsetzt, sollte man
> http://de.php.net/ChangeLog-4.php zumindest überfliegen ;-)
> Bei number_format wurde ein Fehlverhalten korrigiert, das ist der Sinn
> einer Bugfix-Release.

Tolle Rede wenig Sinn: Wenn ich nicht selbst den Server administriere auf dem 
die von mir entwickelte Anwendung des Kunden läuft, dann bringt mir das 
herzlich wenig - oder soll ich immer mal wieder nachschauen, ob der Hoster 
nicht doch vielleicht eine neue Version einsetzt - das ist nicht mein Job und 
vor allem werde ich dafür nicht vom bezahlt.

> Wenn es sich um Bugs handelt, werden diese behoben und das ist auch gut so.
> Waerst Du zufrieden, dass ein einmal vorkommender Bug nie behoben wird, nur
> weil Skripte existieren, die diesen Bug 'ausnutzen'?
> Im uebrigen duerfte es doch nicht unbedingt so schwerffallen, die eigenen
> Applikationen anzupassen und number_format fuer php4.3.7 korrekt zu
> benutzen. Search und Replace und gut ist;-) Und es funktioniert auch mit
> Versionen kleiner als 4.3.7.

Natürlich ist es nicht schwer die Scripte anzupassen. Was aber sehr schwierig 
sein kann ist die DB wieder anzupassen, wenn aufgrund dessen dort viel 'Müll' 
erzeugt wurde. Die automatisch versandten Rechnungen an die Kunden des Kunden 
kann ich auch nicht wieder rückgängig machen... 
Also nicht 'nur mal eben Search and Replace'.... da kann wesentlich mehr 
dranhängen wenn Du mal drüber nachdenkst.

> > Vielleicht fällt jetzt irgendjemandem auf, daß es unlogisch ist wenn
> > mktime eine andere Anordnung der Parameter hat als die anderen
> > Zeitbefehle und es wird dann auch mal kurzerhand angepasst... dann ist
> > das Chaos perfekt....
>
> Warum sollte das passieren? Solange es diesbezueglich keinen
> Bug/Notwendigkeit gibt das zu tun, geht die Wahrscheinlichkeit fuer so
> etwas gegen 0.

Ich hatte auch nie damit gerechnet, daß der Befehl number_format geändert 
wird, da ich davon ausgegangen bin, daß niemand keinen Trenner als Trenner 
benötigt. Auf den Fall 'leere Angabe' geht die Doku nämlich garnicht ein und 
bei Angabe von lediglich zwei Parametern wird ein Punkt als Trenner gesetzt - 
liegt doch nahe, daß es also bislang korrekt funktioniert hat - hat es aber 
wohl nicht ,-)

> > Was haltet ihr davon bzw. ist es überhaupt schon jemandem aufgefallen?
>
> s.o. Bugs sind dazu da, behoben zu werden ;-) und das mit number_format ist
> imho nicht wild.

Es kann ganz schön wild sein - da gibt es viele Scenarien die man sich mit 
etwas Fantasie ausmalen kann.

> Mit Minus meinst Du bug-fixing? Klar ist das nicht immer ganz durchsichtig,
> aber i.A. wird versucht und wird großer Wert auf BC gelegt.
> Ich kann das nicht als Minus werten, aber da kann und soll sich jeder seine
> eigene Meinung zu bilden;-)

Nein ich meine nicht Bugfixing an sich sondern das Umbauen des Verhaltens 
einer Funktion.

> Was waere denn fuer dich die Alternative zur Korrektur von number_format
> gewesen? Immerhin steht es im changelog, gibt den Leuten die Chance es zu
> wissen.....

Es gibt einem die Chance es zu wissen aber nicht unbedingt es rechtzeitg zu 
beheben. wie wäre es denn mit FALSE als Parameter und einem Hinweis daß es in 
der nächsten Version oder ab Version 5 dann endgültig geändert wird?

Viele Grüße,
Jürgen


php::bar PHP Wiki   -   Listenarchive