nicht angemeldet
Re:
Objektnamen gibt man nicht als Strings an, wenn es nicht nötig ist. Wenn man den Namen mal ändern will, wird das automatisierte Refactoring schwierig. Wenn man irgendwann den Code in einer Funktion kapseln will, um ihn mit anderen Scripten zusammenarbeiten zu lassen, dann gibts keine globalen Funktionen mehr. Der Code würde unverändert weiter funktionieren, wenn man nicht window["funktionsname"], sondern mit Funktionsreferenzen gearbeitet hätte.
Nicht jeder verfährt nach dem Konzept "Objekt ist gut™", da die ja so schön portabel sind, weil eierlegende Wollmilchsäue in der Programmierung von jeher ein graus sein sollten. Dementsprechend gebe ich aus verschiedenen, weiteren Gründen einer Einpassung von Code, also deren problemorientierten und zumeist nicht portablen Routinen, jedenfalls den Vorrang. Alles andere wäre für mich Dreamwave & Co bzw. Overhead.
Aber lass uns nochmals auf ein anderen Einwurf von Dir eingehen:
| | - Keine zentrale Initialisierungsfunktion
Die Nutzung von onload hat eben aus Gründen der Übersichtlichkeit und Wartbarkeit von Code i. V. m. einer zentralen Initialisierungsfunktion große Vorteile. In einer Initialisierungsfunktion kann ich ganz einfach mittels alert(initial_array) und ähnlichen Hilfsmitteln mir sehr schnell einen Überblick verschaffen. Ich muss auch nicht lange in den Gesamten Scripten und Dokumenten eines Projektes wühlen, um die Initialisierung zu ermitteln. Ich muss nur <body> ausfindig machen und gucke mir an, was im onload steht.
...Warum das Rad neu erfinden,...
Richtig: <body onload="initial_funktion()">
Kein zusätzlicher workarounds für den IE notwendig, übersichtlich und wartbar.
Das ist viel unflexibler als eine Lösung mit Referenzen. Wenn man seine JavaScripte organisiert, Object-Literale, OOP oder andere Design Pattern verwendet, dann kann man gar nicht mit dutzenden losen globalen Funktionen arbeiten.
Triviale Probleme bedürfen keiner Objekte. Daran scheiden sich hier offensichtlich die Geister. Für das Originalproblem des Threads halte ich addEvent() für eine Alternative, Objekte, wie Du sie jetzt zum Argument instrumentalisierst, berühren das Thema IMHO jedoch gar nicht. Zudem steht immer noch Dein Einwurf bei einem Beispiel, der Performance wegen, dem entgegen, dass man lieber nicht mit Kanonen auf seine Spatzen schießen sollte.
Letzteres verleitet einen nur dazu, den globalen Namespace ungeordnet vollzuballern, was man bestenfalls von Anfang an vermeiden sollte.
Das halte ich für kein diskussionswürdiges Argument, da es nur um einen einzigen Variablennamen geht.
addEvent(window, "load", Modul.init); kann man gar nicht mit Funktionsnamen in einem String umsetzen.
Womit wir wieder bei der Notwendigkeit von Objekten wären...
Mathias, schreib, was Du willst! Ich wäre auch nicht verlegen, gegen jedes Licht, was Du neu wirfst, auch den Schatten daran zu umreisen. Gib einfach bescheid, wenn Du Schwarzweiß in Form von Schach oder Go bevorzugen solltest. ;)
Gruß aus Berlin!
eddi
VEB Opel, Geruchsproben und Stasi 2.0, Zensur...
IHR WOLLTET MERKEL!
Struppi