it’s not the first time i’m annoyed by php, and surely not the last one. i’ve often called php an ad-hoc language, which is changed a lot and contains many inconsistencies. and often tends to break backwards compatibility. for example, i recently upgraded to php 5.3 (while upgrading the server; before, it was running 5.2 if i recall correctly). this instantly broke the openid server i’m using to login to mathoverflow. this was easy to fix, apparently some behaviour changed and i had to replace two or three lines of codes by almost identical ones to make it work again. now i stumbled about something else, while posting something new on blackness. namely, the member function setdate of the datetime object changed a little bit: on success, it no longer returns null, but the object itself. (in case of an error, it still returns false.) well, the blackness editor was expecting null to indicate success, and complained that the data was invalid. great.
i mean, its nicer to return the object (to allow cascadation, at least if one is sure no error occurs – otherwise one is screwed), but why just change this between two versions?! such changes make upgrading php a russian roulette: it might break your programs. and in many cases (like this), it might take you a long time to find out that your program is broken. and when you found out it’s broken, you have to search for the problem, identify it, only to find out that php just changed the rules a little bit. this is just bad. and yet another reason not to use php for anything serious.
(and a programming language not useable for anything serious is, well, to be bluntly: a big pile of crap.)
felix.
settings.
other languages.
pages.
friends.
things i like to read.
categories.
recent posts.
archives.
places.
europe finland lapland ivalo france germany baden-württemberg lower saxony oldenburg north rhine-westphalia lüdinghausen saxony sächsische schweiz norway scandinavia lappland switzerland alps basel pratteln z-7 central switzerland glarus graubünden engadine ticino zürich zürcher oberland hinwil zürich üetliberg north america canada alberta calgary rocky mountains jasper newfoundland yukon oceans
comments.
Ich möchte PHP nicht in Schutz nehmen, aber die Frage ist ja, wie man die Versionsnummern liest.
5.2 zu 5.3 ist ja kein soo kleiner Schritt wie vielleicht manche denken und zwischen beiden Versionen liegen 3 Jahre (und sie haben 5.2 immerhin 4 Jahre weiter gepflegt!). Andererseits wurde DateTime erst in 5.2 hinzugefügt. Das heißt sie haben eine häßliche API (ich finde auch schöner, wenn das Objekt zurückgegeben wird!) bei nächster Gelegenheit korrigiert. Bei einigen anderen Sprachen wie z.B. R kann man erleben, was passiert, wenn offensichtlich ungünstige Entscheidungen auf Grund von Backward-Kompatibilität nie korrigiert werden. Wenn man nicht den Mut zur Korrektur/Verbesserung hat, wird die Sprache irgendwann auch so unbenutzbar (man könnte jetzt lästern, dass das PHP auch nicht mehr hilft, aber…)
Naja, akzeptiert man, dass PHP 5.2 zu 5.3 Änderungen an der API vornehmen darf (und das es diese gibt, verkünden sie ja durchaus!), so sollten sich diese jedoch sehr gut an zentraler Stelle (und nicht nur auf der DateTime::setDate-Seite) dokumentiert finden. Für dein Problem kann ich dies jedoch weder hier noch hier.
es ist schon ok, wenn ab und an die api verändert wird, jedoch sollte man das nur sehr selten machen (am besten mit grossen versionssprüngen) und gut dokumentieren. und halt nur auf wenige, wirklich ungünstige fälle beschränken.
und noch besser: man sollte eigentlich gleich beim designen der api genauer darüber nachdenken, so dass änderungen wenn möglich gar nicht nötig sind. das “ursprüngliche” php ist ja schon ziemlich verhunzt (wenn man sich allein die zig verschiedenen namenskonventionen für funktionen anschaut, die da vermengt werden), da kann man ruhig mal etwas besser aufräumen. aber gerade bei so neuen apis wie das datetime-objekt muss man doch nicht gleich wieder etwas ändern. (hinzufügen ist etwas anderes, das ist nicht so sehr ein problem.)
und ja, dokumentation ist wichtig, gerade wenn man eben doch so etwas ändert. das problem, was ich bei dem openid-server hatte, ist ebenfalls nicht in der von dir verlinkten liste aufgeführt. (es wurde der befehl session_is_registered benutzt, der nun offenbar deprecated ist.)
Die Frage ist halt, was große Versionssprünge sind … (Sun Java hat sich bei 1.5 vermutlich deswegen entschieden zu ganzen Zahlen überzugehen). Und auch z.B. Python hatte immer einen Abschnitt “Porting to Python 2.x” for x in range(1,8), auch wenn sich da deutlich weniger und seltener zutreffende API-Änderungen befinden.
Zu “aber gerade bei so neuen apis wie das datetime-objekt muss man doch nicht gleich wieder etwas ändern”: Sondern lieber ein paar Jahre später, wenn alle sich schon dran gewöhnt haben? Meine Meinung ist da anders.
Und wenn ich alle paar Jahre eine DIN-A4-Seite oder zwei mit API-Änderungen bekomme, von denen viele mich nicht betreffen und nach denen ich meine Programme einfach aktualisieren kann (und die von die beschriebene Änderungen erfordern ja nicht grundlegendes Umschreiben), kann ich damit leben. Sicher, am besten alles gleich richtig machen.
Im Grunde stimme ich Dir ja aber bei deiner Kritik zu. Backward-Kompatibilität ist aber für mich nicht alles.
P.S.: Du hast bisher noch nicht Ruby on Rails benutzt, oder?
nee, ruby und auch ruby-on-rails hab ich bisher nicht genutzt.
zu php 5.3 bin ich übrigens gekommen, als ich den server neu aufgesetzt habe und beim aktuellen ubuntu php5 nicht mehr auf php 5.2.x zeigte, sondern auf php 5.3.y. da kommt man auch gar nicht auf die idee, dass bei einem nicht-sprung von php5 auf php5 plötzlich code anders interpretiert wird… :)
zu php bin ich auch nur “dank” wordpress gekommen, ansonsten würd mir so ein teufelszeug nicht einfach so auf den server kommen ;-)
Das ist mir auch aufgefallen. Ich kann die Pakete python2.6 oder python2.7 installieren, aber bei php gibt es nur php5 (welches bei meinem Debian stable noch 5.2.6 ist).