tags:

views:

441

answers:

5

From a design perspective, I wonder why the .NET creators chose System.Object.GetType() instead of a System.Object.Type read-only property.

Is it just a (very minor) design flaw or is there rationale behind there? Any lights welcome.

+5  A: 

The guidelines say that a property should represent a state of the object, it should not be expensive performance wise, and it should not have side effects apart from computing/setting that state. My guess is GetType() does not respect these rules so they made it a method.

GetType() is a slightly expensive operation. If it were a property it would encourage uses like

DoStuff(obj.Type);
....
DoStuff(obj.Type);

etc.

instead of

Type type = obj.GetType();
DoStuff(type);
....
DoStuff(type);

and that would be not so optimal. So they made it a method to suggest that it should be called sparingly.

AZ
On the other hand, it does represent the state of an object, because the type can't change over the lifetime of an object.
Philippe Leybaert
I would rather see the former code. Optimise for readability first. When you say it's "slightly expensive", how expensive are we really talking? On my NC10 netbook, 10 million calls to GetType() took about 200ms. That's significantly faster than a property which just synchronizes and then returns a private variable. (A trivial property is faster still, admittedly...) I don't think this is a good reason to make it a method.
Jon Skeet
mea culpa for not measuring first. but we need to keep in mind that the method is there from 1.0 and it could have been slower those days.just my 2 cents. anyway - i've just been "skeeted" :). and that's a good thing
AZ
+2  A: 

As I understand it, it is in general considered good practice for internal fields or values which are trivial to calculate to be exposed using a property, and other values, which may require more time or other resources to calculate, to be exposed using a method.

Joel in Gö
+1  A: 

Only Microsoft can answer that question, but I think it's because several classes in the .NET Framework create their own overloaded versions of GetType() with extra parameters. If it would have been a property, they couldn't use the same name (because properties don't have parameters).

Just my thoughts on the subject.

Philippe Leybaert
+12  A: 

If you look at the GetType() declaration in Reflector you'll find this:

[MethodImplAttribute(MethodImplOptions.InternalCall)]
public extern Type GetType();

What that combination of attribute and extern means is that this method is actually implemented in unmanaged code inside the .NET runtime itself. The GUID question in this article goes into further details. They obviously did this for performance reasons after determining that figuring out the Type would be faster if handled at a lower level.

This leads to two reasons not to implement the GetType method as a property. Firstly you can't define properties extern as you can with methods, so it would need to be handled in native .NET code. Secondly even if you could define them as extern, performing an unsafe, unmanaged call from inside a property would definitely break the guidelines for property usage since it's much harder to guarantee that there are no side effects.

Martin Harris
+1. didn't think of reflecting over it
AZ
+1  A: 

A bit late reply but crashed into the question while trying to find something related.

It is possible for GetType to throw an exception. Framework guidelines state that properties should not throw exceptions. This is one more reason why it should be a method instead of property.

Mikko Rantanen
Mikko, according to the docs, GetType() doesn't throw any exception.
Serge - appTranslator