nicht angemeldet
Für ein möglichst "liberales" Framework z.B. sollte diese Option mit einem console.debug("Bitte in Zukunft soundso aufrufen") aber trotzdem gegeben sein.
Solche Sachen macht man, wenn man einmal eine schlechte API definiert hat, dann merkt, dass sie schlecht war, und sie neu konzipiert, aber in der neuen Version noch abwärtskompatibel bleiben will. Dann erklärt man die API für »deprecated«, lässt sie auslaufen und entfernt sie irgendwann ganz.
Wenn man jedoch eine API von Grund auf neu definiert, definiert man keine solchen schlechten Kompromisse. Bzw. folgendes sollte man natürlich: Prüfen, ob die Methoden korrekt aufgerufen werden, und wenn nicht, dann hat es Fehler zu hageln! Mit allem anderen (z.B. Meldungen in der Konsole - die gar nicht jeder Browser hat, in die JavaScript-Autoren nicht reinschauen, sofern kein Fehler passiert) tut man dem Programmierer überhaupt keinen Gefallen, sondern sorgt nur dafür, dass der Fehler in sein Programm einbaut, die ihm früher oder später zum Verhängnis werden.
Ein Framework hat nicht liberal zu sein, sondern eine wohl definierte und eindeutige API zu implementieren. Die kann natürlich flexibel sein (z.B. Function Overloading), solange sie konsistent bleibt. Der Unterschied zwischen Funktionsaufruf und Konstruktoraufruf ist jedoch konzeptionell gesehen ein Unterschied ums Ganze - auch wenn es in JavaScript intern nur ein kleiner Unterschied ist (einmal wird die Funktion im Kontext eines frischen Objects, einmal im globalen Kontext ausgeführt). Wer den Unterschied nicht kennt oder ignoriert und mithilfe einer solchen »liberalen« API gänzlich einebnet, sollte m.M.n. keine objektorientierten Bibliotheken verwenden. Wenn OOP-Pattern letztlich optional sind, kann man sich die ganze Abstraktion auch sparen. Wieso sollte ich mir eine sinnhafte Objektmodellierung ausdenken und gleichzeitig eine Möglichkeit anbieten, das Konzept zu untergraben?
Mathias
Struppi