Warum sind Windows.Forms im System und nicht Microsoft?

Ich hatte immer die Idee, dass der Root-Namespace in .NET, "System", hauptsächlich für Dinge gedacht war, die nicht zu sehr von einer bestimmten Plattform abhingen.Warum sind Windows.Forms im System und nicht Microsoft?

Ich habe mich gefragt, ob jemand irgendwelche Ideen hatte oder Einblick, warum die Windows.Forms Namespace ist in System und nicht Microsoft, da es scheint in einer Plattform ziemlich verankert werden.

(keine Flamme Kriege oder unnötige MS bashing wenn möglich bitte! :))

Quelle

2009-07-23 mcjabberz

Eigentlich können Windows.Forms auch in Mono verwendet werden und daher auch für Mac OS X und $ your_linux_distribution kompiliert werden. – Residuum

Mach dir keine Sorgen über Flammenkriege. Das ist ziemlich selten hier. Diese Art von Antworten würden abgelehnt und verlieren das Interesse ziemlich schnell. –

Interessante Frage - Ich würde auch gerne wissen, wie MS entscheidet, was in System und was in Microsoft geht.Zu viele Dinge in System scheinen in Windows eingebunden zu sein und zu viele Dinge in Microsoft könnten auf alternativen Plattformen funktionieren. – Keith

ich irgendwo gelesen, dass die System.* Namensräume für Dinge, die sind Teil des Kerns NET Framework sind, während die Microsoft.* Namespaces sind für zusätzliche "Value-Added" optionale Extras oder Dinge, die sich in der Entwicklung befinden.

EDIT:

Brad Abrams hat eine Diskussion darüber in seinem Blog-Post What Does that .NET Namespace Mean: System.* and Microsoft.*

Zusätzlich ein Zitat von Visual Basic 2005 mit .NET 3.0-Programmierreferenz:

Der Microsoft-Stammnamespace enthält Microsoft-spezifische Elemente. Theoretisch kann jeder Anbieter .NET-Sprachen implementieren, die in Intermediate Language (IL) -Code übersetzt werden. Wenn Sie eine solche Sprache erstellen würden, würden die Elemente im Microsoft-Namespace normalerweise nicht für Ihre Sprache gelten. Elemente im Systemnamespace ... wären für Benutzer Ihrer Sprache ebenso nützlich wie für Programmierer, die die Microsoft-Sprachen verwenden, aber die Elemente im Microsoft-Namespace wären wahrscheinlich nicht so hilfreich.

Dies würde bedeuten, dass, wenn ich eine neue .NET-Sprache zu machen, würde ich in der Lage wäre, die Nutzung des System.Windows.Forms Namespace machen UIs zu machen, aber ich würde wahrscheinlich nicht viel für die Klassen in Microsoft.* Namensräumen haben.

Quelle

2009-07-23 21:58:46 adrianbanks

Sehr guter Punkt! Ich habe es nie so gedacht, aber es macht viel Sinn. – mcjabberz

Meine Vermutung wäre:

Microsoft stellte sich die .NET-Framework als die Fähigkeit, Multi-Plattform zu sein, aber sie waren nur eine Laufzeitumgebung für die Windows-Plattform zur Verfügung zu stellen würde. Sie gingen wahrscheinlich davon aus, dass jeder, der eine Laufzeitumgebung für eine andere Plattform bereitstellt, diese so implementieren würde, dass System.Forms verwendet werden könnte. Die Laufzeitumgebung würde die Unterschiede zwischen den nativen Implementierungen behandeln.

Quelle

2009-07-23 21:58:49

Nicht besonders glaubwürdig, wenn man bedenkt, wie gebunden System.Forms an User32 ist. – EFraim

Sehr wahr. Ich hoffe, dass der Namespace vielleicht vor der Implementierung konzipiert wurde ... und die Implementierung war nicht so, wie sie es sich vorgestellt hatte. Zweifelhaft, ich weiß. –

@EFraim Nicht wirklich. Sicher, die Implementierung abstrahiert nicht viel, aber das ist nicht notwendig, wenn Sie Ihre eigene Laufzeit implementieren - Sie ersetzen das Ganze sowieso. Aber während das grundlegende UI-Zeug von Windows beeinflusst wird, ist es nicht wirklich * an Windows gebunden * (es sei denn * du * verwendest plattformabhängige Dinge, wie zum Beispiel das Überschreiben von 'WndProc'). Mono implementiert Windows.Forms einfach mit jedem Desktop-Manager, den Sie auf Ihrem System haben. – Luaan

Nur weil "Microsoft Windows" auf "Windows" abgekürzt wurde, heißt das nicht, dass das "Fenster" -Konzept nicht breiter ist als Microsoft. Alle Implementierungen von GUIs seit der ursprünglichen IBM PARC-Schnittstelle über Microsoft Windows, X11 usw. beziehen sich alle auf Windows- und Form-Steuerelemente, es ist nur so, dass Microsoft ihre spezielle Implementation "Windows" genannt hat. Daher scheint System.Windows.Forms korrekt zu sein, da es nicht notwendig ist, dass ein Fenster Teil von "Windows" ist. Wahrscheinlich sollte es nur Windows mit einem Kleinbuchstaben w sein. Aber das würde die Namenskonventionen der Namespaces durchbrechen.

Quelle

2009-07-23 22:05:36

Tatsächlich Windows.Forms ist spezialisiert auf das Microsoft (R) Windows-Look & Feel, im Gegensatz zu GTK # und Cocoa # – Residuum

Eigentlich denke ich, dass Sie das Microsoft (R) Windows Aussehen und Gefühl haben, weil Sie Microsoft verwenden (R) Windows. Siehe die Antwort von @adrianbanks. –

Wenn ich Windows.Forms mit mono in Debian Sid kompiliere, bekomme ich immer noch das Aussehen und Verhalten von Microsoft Windows, ähnlich dem Ausführen von Microsoft Windows-Anwendungen mit Wein. – Residuum

Warum sind Windows.Forms im System und nicht Microsoft?

Antwort

Verwandte Themen