Why isn't the Type class in the System.Reflection namespace?

views:

101

answers:

+5 Q:

Why isn't the Type class in the System.Reflection namespace?

Everything about Type is reflective in nature. Is it because Type is used more often than the rest of the classes in System.Reflection? Or because it functions more like a system class than a reflection class?

In short, I've always wondered what the motivation behind the location of System.Type was.

+1 A:

An assembly has types and Assembly lies on System.Reflection which is curious.

So my guess would be that it has something to do with Object implementing the method GetType which returns a Type.

João Angelo 2010-03-19 14:43:25

Incidentally, `Object.getClass` in Java parallels this.

jleedev 2010-03-19 14:45:27

Though by the same logic, shouldn't `MemberInfo` be in the `System` namespace as well? `Type` implements `GetMember()` which returns a `MemberInfo`. Forward-referencing of namespaces happens all over the place within the BCL.

Arc 2010-03-20 15:31:16

@Arc, indeed, but the use case `Object.GetType()` is much more frequently used than `Object.GetType().GetMember()`.

João Angelo 2010-03-21 11:38:59

Very true, though if `Type` is in `System.Reflection` you could still do `o.GetType.FullName` without needing any extra using blocks. Using `Type` for anything else usually requires `using System.Reflection` even when it's located in `System`.

Arc 2010-03-21 20:43:28

Maybe because of Oject.GetType()? Sytem.Reflection has more "advanced" stuff to do.

Al Bundy 2010-03-19 14:55:16

Regardless, they are only namespaces, so having `Type` be in the `System.Reflection` namespace wouldn't effect anything related to `System.Object`. The BCL groups types by functionality and `Type` has reflective functionality.

Arc 2010-03-19 15:15:27

Yes, it has. The same way `String` or even `IFormatProvider` should be in `System.Text`, like `StringBuilder` is, `ThreadStaticAttribute` should be in `System.Threading`. Think of writing the code when for some simple usage of `Type` you would have to import `System.Reflection` and all its members would be available in IntelliSence, name clashing would be more likely etc, YAGNI.

Al Bundy 2010-03-19 17:43:28

Though `System.String` isn't necessarily used for text services. Think of hashes, marshaling, simple dictionary keys, etc. And it also has the feel of a primitive type due to the `string` keyword. `System.Type`, on the other hand, will always be used in metadata contexts and has no equivalent keyword.

Arc 2010-03-20 15:23:24

I guess it's because Object as a GetType method.

MS coding practicing tell that a class should not reference a type in a subnamespace. In practice, the BCL violates this rule quite often ;o)

Cédric Rup 2010-03-19 14:59:03

The Type class is used in a lot more places, not just System.Reflection. A quick search with Reflector reveals hundreds of them. It is crucial in System.Configuration, System.Data, System.Drawing, System.Linq, System.Windows.Forms, etc. The way the Type instance is actually used in these classes isn't visible. It is likely that System.Reflection is used but that's an implementation detail that in no way affects the program.

Given that creating the Type instance that these classes need is trivial with the typeof operator and object.GetType and that you never have to use System.Reflection unless you actually write reflection code, Type certainly deserves an easily accessible location in the System namespace.

Hans Passant 2010-03-19 17:15:06

ansaurus

tags:

views:

answers:

Why isn't the Type class in the System.Reflection namespace?

related questions