Alternative zu eval() für arithmetische Berechnungen

[1unitedpower]

D.h. du siehst dieses Objekt als JavaScript-Implementierung einer Klasse mit statischen Methoden.

Nein, so sehe ich es nicht. Dynamisch bedeutet bloß, dass ein Stück Code von der Laufzeit abhängig ist. Es verhält sich immer angepasst an die Situation. Statisch bedeutet, dass ein Stück Code unabhängig von der Laufzeit ist. Es verhält sich immer gleich, es lässt sich vorhersehen was passiert, indem man einfach nur einen Blick auf die Definition wirft.

Mit "abstrakten Metaklassen" habe ich das nicht in Verbindung bringen wollen. Darunter kann ich mir auch nicht viel vorstellen.

JavaScript hat noch das besondere "Feature", einer Funktion ein beliebiges this unterschieben zu können, und hindert mich auch nicht daran, das bei Methodenaufrufen zu tun.

Das ist gerade das Schmutzige an der Sache. Es wird erst beim Aufruf der Methode entschieden, was this ist. Das ist in allen OOP-Sprachen so, nicht nur in JavaScript. Das ist der berühmte Gorilla mit der Banane, der im Dschungel steht.

“The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.” – Joe Armstrong

In Matthias' Fall wäre opMap die Banane. Man kann direkt danach greifen. this dagegen ist die Banane, in der Hand des Gorillas und dazu der ganze Dschungel.

Und dann bin ich mit deiner Deutung von "kennen" nicht glücklich. Dass die Methoden des opMap-Objekts die Variable "opMap" sehen, weil sie im gleichen Kontext liegen, heißt ja noch nicht, dass sie sie auch benutzen sollten.

Wenn man versucht vorhersehbaren und leserlichen Code zu schreiben, dann sollte man das. Der lexikalische Scope bedeutet äußerst hohe Lokalität und Kohärenz.

Objekte sollten nicht eigenständig aus sich hinausgreifen. Wenn sie was brauchen, muss man es ihnen liefern. Alles andere führt zu langfaserigem Objektfilz.

Hier überschlägst du dich. Was verstehst du unter "hinausgreifen"? Ein Griff in die lexikalische Umgebung ist jedenfalls einem Griff in die Laufzeit-Umgebung vorzuziehen.

Ja, du hast recht, statischer Code ist - solange er nicht zu groß wird - einfacher zu erfassen. Wird er größer, entstehen viel zu viele Abhängigkeiten und nicht mehr wartbares Chaos.

Da sind meine Erfahrungen anders. Dynamischer Code ist im Kleinen schon schwierig zu verstehen und die Komplexität wächst über-proportional mit der Menge des Codes. Je mehr Laufzeitkontext man berücksichtigen muss, desto schwieriger wird es den Code zu verstehen. Der statische Ansatz reduziert Code-Abhängigkeiten um eine Vielfaches, indem Laufzeit-Abhängigkeiten kategorisch ausgeschlossen werden. Man gerät also gar nicht erst so schnell in die Dependency-Hell. Und noch was: In Sprachen ganz ohne dynamische Features, Haskell zum Beispiel, gibts gar keine andere Möglichkeiten als Abhängigkeiten per DI aufzulösen. Abhängigkeiten sind immer explizit, nie implizit.

Auch das ist eine Eigenschaft von Menschen: Wir sind Gewohnheitstiere. Gewohnheiten zu meiden, die sich als schädlich herausstellen können, ist daher eine nützliche Sache.

Da sind wir uns einig, und this ist in JavaScript bekannt für seine Fehleranfälligkiet und Unvorhersehbarkeit. Closures dagegen haben sich als zuverlässige Lösung etabliert.