nicht angemeldet
das heißt, wenn _das_ schiefgeht, funktioniert ggf. gar nichts mehr richtig, weil die Verzweigungen immer wieder auf diesem ermittelten Wert basieren. Und daß Sniffing die schlechtest-mögliche Ermittlungsgstategie eine(s|r) Browser(s|version) ist, sollte bekannt sein. Sogar JQuery hat es in den neuesten Versioenen nach langem Kampf inzwischen abgeschafft.
Was heißt denn »selbst jQuery« - soweit ich weiß, ist jQuery die erste Bibliothek, die ihre Strategie diesbezüglich grundsätzlich ändert. Dadurch ändert sich intern erstmal nicht alles zum Positiven. Das Browsersniffing wurde keineswegs willkürlich verwendet, sondern dann, wenn die üblichen Objektabfragen nicht zum Ziel geführt haben. Jetzt müssen am Anfang erstmal einige Feature-Erkennungen laufen, damit die Bibliothek auf diesen aufbauen kann. Browserbugs und -eigenheiten durch Tests zu erkennen, ist dann wieder eine Wissenschaft für sich und kann genauso fehlerträchtig sein.
Insofern mag sich der Verzicht auf Browsererkennung über navigator irgendwie zukunftssicherer anfühlen, aber ob sich das an den schwierigen Stellen in der Praxis bewährt, halte ich immer noch für unentschieden.
- Prototype.js erweitert im großen Stil die Basis-Objekte (die Meinungen, ob das schlecht ist, sind allerdings sehr geteilt; Crockford z.B. befürwortet es, solange es in einem sehr kontrollierten Rahmen bleibt).
Wirklich elegant kommt man nicht heraus - entweder man baut sich seine eigene Objekthierarchie mit 29 Namespaces, baut abgeleitete, erweiterte Objekttypen (MyString, MyNumber, MyArray) oder erweitert schlicht die bestehenden Objekttypen prototypisch, wie es das Grundkonzept von JavaScript nahelegt. Um alle Probleme dabei zu umschiffen, fehlen JavaScript gewisse OO-Fähigkeiten.
Texte zu den Problemen, die manche damit sehen: 1 en
»Prototype makes associative arrays unreliable when it comes to using the for(x in array) loop.«
Ja ach. Da hat gerade jemand die Prototype Chain entdeckt. It's a bug, not a feature! Es lassen sich nunmal keine nicht-enumerable member in ECMAScript setzen. Das ist vielmehr eine Schwäche von ECMAScript als ein Argument gegen die Verwendung des Prototype-Objektes. Bei for-in ist IMMER hasOwnProperty zu nutzen. Erweiterungen wie Function.prototype.bind sind ultrapraktisch und genial!
»When a method is added to a JavaScript implementation, the then native method and the previously user defined method may not be exactly the same which breaks programs. Real cases of this problem have occurred. We need to learn from history and improve our practices accordingly.«
Sprachen und Interpreter entwickeln sich halt weiter (derzeit vor allem proprietär) und das, was man früher selbst einbauen musste, bringen sie in neueren Versionen mit sich. Als ob das Problem nur JavaScript beträfe.
Wenn ein Script also zu einer neuen Sprach- oder Interpreterversion kompatibel sein soll, dann ist eine Migration angesagt. Das gilt natürlich verschärft für Erweiterung der Kernobjekt-Prototypen, aber das würde ich nur als Teil eines größeren Problems sehen. if (document.all) else if (document.layers) war seinerzeit angebracht, aber neue Techniken und Interpreter kamen, sodass diese Scripte überarbeitet werden mussten. Das sind m.E. einfach die Grenzen von Vorwärtskompatibilität. Um die muss man wissen, wenn man versucht, durch prototypische Erweiterung Lücken zu schließen. Aber das war es auch. Die Welt wird nicht untergehen.
... zeigt mit seiner Diskussionskultur lediglich deutlich, warum man dem Usenet und dessen Gestalten vor allem den Rücken zukehren sollte.
Also ich habe bei der Lektüre überhaupt nichts gelernt. Kannst du das nochmal für mich zusammenfassen? Vielleicht habe ich einfach eine zu unterschiedliche Perspektive, als dass ich solchen Spiegelfechtereien etwas abgewinnen könnte.
Mathias
Struppi