J'ai toujours eu l'idée que l'espace de noms root dans .NET, " Je me demandais si quelqu'un avait des idées ou une idée de la raison pour laquelle le (pas de guerre de flamme ni de matignure inutile si possible s'il vous plaît! :)) système ", était principalement destiné à des choses qui ne dépendent pas trop sur une plate-forme particulière.
Windows.Forms est dans système et non Microsoft car il semble être assez enraciné dans une plate-forme.
3 Réponses :
J'ai lu quelque part que le système EDIT:
Brad Abrams a une discussion à ce sujet dans son blog post qu'est-ce que cet espace de noms ?NET signifie: système. * et Microsoft. *
En outre, une citation de Visual Basic 2005 avec référence de programmation .NET 3.0 :
L'espace de noms de la racine Microsoft contient des éléments spécifiques à Microsoft. En théorie, tout fournisseur peut mettre en œuvre des langues .NET qui se traduisent par code de langue intermédiaire (IL). Si vous deviez construire une telle langue, les éléments de l'espace de noms Microsoft ne s'appliqueraient généralement pas à votre langue. Les articles de l'espace de noms système ... seraient aussi utiles pour les utilisateurs de votre langue, car ils sont aux programmeurs qui utilisent les langues Microsoft, mais les éléments de l'espace de noms Microsoft ne seraient probablement pas aussi utiles.
Cela impliquerait que si je devais faire une nouvelle langue .NET, je serais en mesure d'utiliser le . * Les espaces de noms sont pour des éléments qui font partie de la structure de base .NET, tandis que le Microsoft. * Les espaces de noms sont pour une "valeur supplémentaire -Ajouté "des extras optionnels ou des choses en développement.
System.Windows.Forms Espace de noms pour faire de l'UIS, mais je n'aurais probablement pas Beaucoup d'utilisation pour les classes dans Microsoft. * Namespaces.
Très bon point! Jamais pensé de cette façon, mais c'est effectivement logique.
Je suppose que ce serait:
Microsoft a envisagé le framework .NET comme ayant la possibilité d'être multi-plate-forme, mais ils allaient uniquement fournir un environnement d'exécution pour la plate-forme Windows. Ils ont probablement supposé que quiconque fournissant un environnement d'exécution pour une autre plate-forme la mettrait en œuvre de manière à pouvoir utiliser System.Forms. Le temps d'exécution traiterait les différences entre les impléménations indigènes.
Pas particulièrement crédible, compte tenu de la manière dont System.Forms est à l'utilisateur32.
Très vrai. Je continue à espérer que peut-être que l'espace de noms a été conçu avant la mise en œuvre ... et la mise en œuvre n'était pas ce qu'elles envisagées. Douteux, je sais.
@Efraïm pas vraiment. Bien sûr, la mise en œuvre ne se résume pas beaucoup, mais ce n'est pas nécessaire lorsque vous mettez en œuvre votre propre runtime - vous remplacez la totalité de toute façon. Mais alors que les substances de base de l'interface utilisateur sont influencées par Windows, ce n'est pas vraiment attaché à Windows (sauf si vous utiliser des choses dépendant de la plate-forme, comme le remplacement wndproc ). Mono implémente Windows.Forms très bien avec le gestionnaire de bureau que vous avez sur votre système.
Juste parce que "Microsoft Windows" a été abrégé à "Windows" dans NON signifie que le concept "Fenêtre" n'est pas plus large que Microsoft. Toutes les implémentations de Guis depuis l'interface de Parc IBM d'origine via Microsoft Windows, X11, etc. font tous référence à Windows et contrôles de formulaire, il est juste que Microsoft a appelé leur implication particulière "Windows". Ainsi, System.Windows.Forms semble correct car il n'est pas nécessaire pour une fenêtre de faire partie de "Windows". Probablement à cela devrait être juste des fenêtres avec une minuscule avec un. Mais cela briserait les conventions de nom des espaces de noms.
En réalité, Windows.Forms est spécialisé pour l'apparence et la sensation de Windows Microsoft (R), par opposition à GTK # et au cacao #
En fait, je pense que la raison pour laquelle vous obtenez le ressort de Windows Microsoft (R) est que vous utilisez des fenêtres Microsoft (R). Voir la réponse par @adrianbanks.
Lorsque je compile Windows.Forms avec Mono à Debian Sid, je reçois toujours l'apparence de Microsoft Windows, similaire à la gestion des applications Microsoft Windows avec Wine.
En fait, Windows.Forms peut également être utilisé dans Mono, et donc également compilé pour Mac OS X et $ votre_Linux_Distribution.
Ne vous inquiétez pas pour les guerres de flamme. C'est assez rare ici. Ces types de réponses seraient révélés et perdent l'intérêt assez rapidement.
Question intéressante - J'aimerais aussi savoir comment MS Décide ce qui se passe dans le système et ce qui se passe dans Microsoft. Trop de choses dans le système semblent être liées à Windows et trop de choses dans Microsoft pourraient travailler sur des plates-formes alternatives.