Why System. when creating new objects?

Quick question!

Can someone explain why you would define a new object as such(using Datatable as example):

System.Data.DataTable dt = new DataTable();

..Instead of..

DataTable dt = new DataTable();

What's the difference????

Thanks in advance!!!

There is no difference.
If you are

using System.Data;

in your class you no longer have to type that out.

That's what I suspected. I've seen some examples where the developer is 'using System.??' and still defines objects as 'System.??.object.

Hmmm!! A little overkill maybe??

Thanks!!

It happens. Sometimes you forget you Imported the namespaces. Or you copy and pasted some code from somewhere that had it verbose like that and didnt change it. No big deal either way. Dont think it changes performance in any way.

Quote:

---

Originally posted by Cander
In Soviet Russia, applications program you!

---

Cander, in Soviet Russia 99% of people didn't use apps. however Government programmed people :)

Overkill no doubt, but for a good reason, sometimes, especially when code is generated. Cander is right that it does not change performance - it's just a shortcut so we don't have to type so much.

The good reason is to avoid ambiguity. Even the code, for example, when you add a button in the IDE, looks like this in a Windows Form project

Code:

---

private System.Windows.Forms.Button btnCancel;

---

VS automatically adds the

Code:

---

using System.Windows.Forms;

---

so it would seem redundant. Problem might be, what if I decide to make my own Button class? When it's fully qualified, ambiguity is not a problem.

Mike

Right - there are even a few ambiguously named classes within the .NET Framework itself (in System.Drawing vs System.Windows.Form, IIRC)

I always add the usings I need manually to the class anyway. I dont assume everyone that may use a class I wrote will be using VS. So its good that the class is self sufficient and not depending on VS specific files.

Thanks for your input to all. I agree!!