Auch ist mir nicht ersichtlich, warum
function bla () {}
addEvent(window, "load", bla);
Modul = {
init: function () {}
};
addEvent(window, "load", Modul.init);
>
> hinter jedem "Modul" eleganter sein soll, als folgendes:
>
> `f.push('functionsname');`{:.language-javascript}
Weil es von der Funktionalität her etwas anderes ist und andere Möglichkeiten bietet.
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.
In JavaScript sind i.d.R. nur Objekt-Referenzen interessant, nicht deren globale Namen. Mit Funktionsreferenzen arbeitet man beim Event-Handling eigentlich immer, ob man nun traditionelles Handling, addEventListener, attachEvent oder ein eigenes addEvent benutzt. Warum das Rad neu erfinden, indem man für window.onload plötzlich auf eine Lösung mit Strings mit Namen globaler Funktionen setzt. Das ist viel unflexibler als eine Lösung mit Referenzen. Wenn man seine JavaScripte [organisiert](http://aktuell.de.selfhtml.org/artikel/javascript/organisation/), Object-Literale, OOP oder andere Design Pattern verwendet, dann kann man gar nicht mit dutzenden losen globalen Funktionen arbeiten. Letzteres verleitet einen nur dazu, den globalen Namespace ungeordnet vollzuballern, was man bestenfalls von Anfang an vermeiden sollte. addEvent(window, "load", Modul.init); kann man gar nicht mit Funktionsnamen in einem String umsetzen.
Mathias
--
[JavaScript-Erweiterung für das SELFHTML-Forum](http://molily.de/selfhtml-forum-js/)