Es sieht so aus, als würden Sie die Terminologie von "Namespace" und "Modul" überladen. Es sollte keine Überraschung sein, dass Sie Dinge als "indirekt" betrachten, wenn sie nicht Ihren Definitionen entsprechen.
In den meisten Sprachen, die Namespaces unterstützen, einschließlich C #, ist ein Namespace kein Modul. Ein Namespace ist eine Möglichkeit, Namen zu erfassen. Module sind eine Möglichkeit, das Verhalten zu bestimmen.
Während die .Net-Laufzeit die Idee eines Moduls unterstützt (mit einer etwas anderen Definition als der, die Sie implizit verwenden), wird sie im Allgemeinen eher selten verwendet. Ich habe es nur in Projekten gesehen, die in SharpDevelop erstellt wurden, hauptsächlich, damit Sie eine einzelne DLL aus Modulen erstellen können, die in verschiedenen Sprachen erstellt wurden. Stattdessen erstellen wir Bibliotheken mithilfe einer dynamisch verknüpften Bibliothek.
In C # werden Namespaces ohne "Indirektionsebene" aufgelöst, solange sie sich alle in derselben Binärdatei befinden. Jede erforderliche Indirektion liegt in der Verantwortung des Compilers und Linkers, über die Sie nicht viel nachdenken müssen. Sobald Sie mit dem Erstellen eines Projekts mit mehreren Abhängigkeiten beginnen, verweisen Sie auf externe Bibliotheken. Sobald Ihr Projekt auf eine externe Bibliothek (DLL) verwiesen hat, findet der Compiler diese für Sie.
Wenn Sie im Schema eine externe Bibliothek laden müssen, müssen Sie zunächst etwas tun (#%require (lib "mylib.ss"))oder die Fremdfunktionsschnittstelle direkt verwenden, wie ich mich erinnere. Wenn Sie externe Binärdateien verwenden, haben Sie den gleichen Arbeitsaufwand, um externe Binärdateien aufzulösen. Möglicherweise haben Sie meistens Bibliotheken verwendet, die so häufig verwendet werden, dass es einen schemabasierten Shim gibt, der diese von Ihnen abstrahiert. Wenn Sie jedoch jemals eine eigene Integration in eine Bibliothek eines Drittanbieters schreiben müssen, müssen Sie im Wesentlichen einige Arbeiten ausführen, um sie zu laden " die Bibliothek.
In Ruby sind Module, Namespaces und Dateinamen weitaus weniger miteinander verbunden, als Sie vermuten. Das LOAD_PATH macht die Dinge etwas kompliziert, und Moduldeklarationen können überall sein. Python ist wahrscheinlich näher dran, Dinge so zu tun, wie Sie es in Schema sehen, außer dass Bibliotheken von Drittanbietern in C immer noch eine (kleine) Falte hinzufügen.
Darüber hinaus haben dynamisch typisierte Sprachen wie Ruby, Python und Lisp normalerweise nicht den gleichen Ansatz für "Verträge" wie statisch typisierte Sprachen. In dynamisch typisierten Sprachen stellen Sie normalerweise nur eine Art "Gentleman-Vereinbarung" her, dass Code auf bestimmte Methoden reagiert, und wenn Ihre Klassen dieselbe Sprache zu sprechen scheinen, ist alles in Ordnung. Statisch typisierte Sprachen verfügen über zusätzliche Mechanismen, um diese Regeln beim Kompilieren durchzusetzen. In C # können Sie durch die Verwendung eines solchen Vertrags zumindest mäßig nützliche Garantien für die Einhaltung dieser Schnittstellen bereitstellen, sodass Sie Plugins und Substitutionen mit einem gewissen Maß an Garantie für die Gemeinsamkeit bündeln können, da Sie alle gegen denselben Vertrag kompilieren. In Ruby oder Scheme überprüfen Sie diese Vereinbarungen, indem Sie Tests schreiben, die zur Laufzeit funktionieren.
Diese Garantien für die Kompilierungszeit bieten einen messbaren Leistungsvorteil, da für einen Methodenaufruf kein doppelter Versand erforderlich ist. Um diese Vorteile in etwas wie Lisp, Ruby, JavaScript oder anderswo nutzen zu können, sind die heute noch leicht exotischen Mechanismen des statischen Just-in-Time-Kompilierens von Klassen in spezialisierten VMs erforderlich.
Eine Sache, für die das C # -Ökosystem noch relativ unausgereift ist, ist die Verwaltung dieser binären Abhängigkeiten. Java hat Maven seit mehreren Jahren damit beschäftigt, sicherzustellen, dass Sie alle erforderlichen Abhängigkeiten haben, während C # immer noch einen ziemlich primitiven MAKE-ähnlichen Ansatz verfolgt, bei dem Dateien strategisch vorzeitig am richtigen Ort platziert werden.