2011-01-05 8 views
7

Mientras reviso algún código heredado, descubrí que puede declarar una clase C# sin colocarla en un espacio de nombres (en este escenario tengo una aplicación ASP.NET WebForms y algunos de los formularios web no declarado dentro de ningún espacio de nombres).Clase AC# con un espacio de nombres nulo

A GetType() en una clase de este tipo devuelve un tipo en el que la propiedad namespace está establecida en null.

No sabía que esto estaba permitido. ¿Alguien puede sugerir por qué sería deseable tener una clase que no está declarada dentro de un espacio de nombres?

+0

Oh, no sé. Creo cosas que no (explícitamente) viven en clases o espacios de nombres todo el tiempo, pero una vez más, estoy usando lenguajes de hackish dínamicos débiles;) – delnan

Respuesta

5

Ciertamente no es una gran práctica. Es hace hace algunos ejemplos más fáciles, como "hola mundo" - tal vez los diseñadores de C# iban por código de golf; p

Pero sí, es una rareza. No estoy al tanto de ninguna razón contundente de que necesite para poder usar directamente el espacio de nombres global. Incluso para los métodos de extensión prefiero añadir una directiva using para que estén en ...

Curiosamente - parece que hay como 40 y pico en mscorlib.dll y 20 y pico en system.dll

var mscorlib = typeof(string).Assembly.GetTypes() 
    .Where(t => string.IsNullOrEmpty(t.Namespace)).ToList(); 
var system = typeof(Uri).Assembly.GetTypes() 
    .Where(t => string.IsNullOrEmpty(t.Namespace)).ToList(); 

(pero todo privado/generado por el compilador)

+0

La única razón que podía pensar era para simplificar los ejemplos simples. Pero el concepto de un espacio de nombres es bastante simple en sí mismo, y uno bastante fundamental también ... –

3

Quizás para permitir la interoperabilidad con lenguajes que no admiten espacios de nombres.

actualización

Después de un poco de espeleología puedo ver un caso que utilice MS.

Todos los ensamblados de .Net Framework tienen algunas clases estándar en el espacio de nombres global, p.

  • FXAssembly: información de la versión.
  • ThisAssembly: información de montaje.
  • AssemblyRef: información de conjunto dependiente.

Estas clases contienen metadatos enlatados que de otro modo serían más difíciles de conseguir. Supongo que eligieron ubicarlos en el espacio de nombres global para que sea una ubicación estándar \ convencional donde tools \ utilities \ etc puedan llegar a ellos. Esta información es una herramienta de arranque \ metainformación que lógicamente se encuentra por encima del concepto de espacios de nombres.

+1

Parece posible, pero no puedo dejar de pensar que ese tipo de lenguaje sería bastante tullido cuando se habla con el BCL –

Cuestiones relacionadas