Große JS-Dateien

[fischlak]

Hallo Felix,

in Objekten hat man automagisch auch seinen eigenen Namespace... cool, gell?

Da könnte ich ja genauso schreiben: "In Inline-Funktionen hat man automagisch auch seinen eigenen Namespace... cool, gell?"...

Du bringst ein klassisches OOP‑Argument: "Wenn du alles in Objekte packst, hast du automatisch Namespaces, also ist globaler Namespace kein Problem."

Das ist die typische Denkrichtung, wenn jemand sehr objektorientiert sozialisiert ist:

• Objekt = Container
• Methoden = automatisch gekapselt
• Namespace = Objektname
• Problem gelöst (aus Deiner Sicht)

Was Du offensichtlich nicht sehen willst: Objekte lösen das eigentliche Problem nicht!

Objekte verhindern globale Namenskollisionen, aber sie lösen nicht:

• schlechte Struktur

• weite Sprünge im Code

• fehlende Nähe zwischen Logik und Verwendung

• mentale Last durch verteilte Definitionen

• Overhead durch künstliche Objekt‑Architektur

• das Problem, dass man für jede Kleinigkeit ein Objekt erfinden muss

Mit anderen Worten: Objekte lösen das Problem des globalen Namespaces, aber nicht das Problem der schlechten Lesbarkeit.

Und mein Punkt ist ja genau: Struktur, Nähe, Folding, lokale Kapselung.

Du versuchst, die allgemeine Kritik am globalen Namespace mit einem OOP‑Argument zu neutralisieren: "Wenn du OOP machst, hast du das Problem nicht." Das ordne ich als ein Paradigmen‑Reflex ein: Du denkst in Klassen, Instanzen, Methoden, Modulen. Ich denke in lokaler Kapselung, Folding, Nähe, mentaler Ergonomie.

Wir reden über zwei verschiedene Ebenen: Du: Paradigma. Ich: Ergonomie und Struktur im Editor.

Sorry, aber Deine Aussage geht am Thema vorbei. Ich habe über lokale Kapselung vs. globaler Namespace gesprochen. Du antwortest mit Objekt‑Namespaces. Das ist, als würde ich sagen:

"Ich mag kleine Werkzeuge, die ich direkt am Arbeitsplatz habe."

Und Du erwiderst:

"Du kannst auch einen Werkzeugwagen im Nebenraum haben."

Beides stimmt – aber es beantwortet nicht mein Argument.

Ich vertrete den Standpunkt, dass jeder Mensch das Recht hat, sich selbst komplett zum Affen zu machen.

Ja, so läuft es oft: Wenn die Argumente fehlen, dann kommen die persönlichen Angriffe...

Warum dann nicht gleich ganz auf Array.forEach() und solche Sachen setzen? Dann kapselst Du Variablen und kannst in Deinem Editor schön zusammenfalten! Klappt bei Objekten sehr schön:

Jetzt wechselst Du das Thema (ohne dass es Dir bewusst ist?). Du antwortest nicht auf mein Argument – Du zeigst mir nur ein Beispiel, das Deinen Stil bestätigt.

Dein Beispiel zeigt einfach Iteration:

Object.keys(o).forEach(property => {
  console.log("Eigenschaft", property);
  console.log("Wert",  o[property]);
});

Das ist ein Beispiel für:

• Iteration

• Nutzung von forEach

• Zugriff auf Objekt‑Properties

Aber es zeigt keinen Ersatz für lokale Inline‑Funktionen, keine lokale Kapselung, keine Nähe von Logik und Verwendung. Es ist einfach nur ein Loop.

Dein Beispiel löst das besprochene Problem nicht. Wenn ich sage:

"Ich will lokale Inline‑Funktionen, weil ich nicht im Code wühlen will."

Und Du sagst:

"Nimm doch Objekte."

Das ist, als würde ich sagen: "Ich mag Schubladen direkt am Schreibtisch."

Und Du sagst: "Dann geh doch zum Werkzeugschrank.“

Beides sind Ordnungssysteme – aber sie lösen verschiedene Probleme.

Ja, Objekte sind super, wenn man Königreiche bauen will! Aber ich brauche manchmal nur einen kleinen Gartenzaun... :-)

Gruß, fischlak

PS: Jetzt hast Du mich tatsächlich noch davon abgebracht, endlich die neue LTS zu installieren :-)