using - am I missing something

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I'm fairly new to C# and I must be misunderstanding something:
I have created a standard web ASP.NET web application project and put data
controls into it. Right at the top is a whole set of 'using' statements put
there automatically by the code generator - for example 'using System' ,and
'using System.Data.
Below that is my class, also with some automaticcaly generated code,
starting with:
protected System.Data.OleDb.OleDbConnection oleDbConnection1;
protected System.Data.OleDb.OleDbDataAdapter oleDbDataAdapter2;
etc.
If I modify these to
protected OleDb.OleDbConnection oleDbConnection1;
protected OleDb.OleDbDataAdapter oleDbDataAdapter2;
then the build fails.
Can someone please explain why these need to have System.Data specified,
when this namespace is already specified in a 'using' statement.
 
Can someone please explain why these need to have System.Data specified,
when this namespace is already specified in a 'using' statement.
Click to expand...

Because System.Data != System.Data.OleDb, even though they happen to
share a common prefix. If you add

using System.Data.OleDb;

you can then change the code to

protected OleDbConnection oleDbConnection1;
protected OleDbDataAdapter oleDbDataAdapter2;



Mattias
 
In addition to what Mattias said,

if using System.Data should make your statement work then question is just
by writing System every thing should work,

e.g.
using System;
....
....
OleDbConnection oleDbConnection1

it should create a object too, right? After all it is some place inside
System namespace.

Actually, it do not work like that. Reason is that using makes methods,
interface, and other stuff inside that namespace visible but not a namespace
in side it for inline use. One of the reason I can think of is that I can
have my own namespace named to be OleDB and it could have all the stuff
other than what you are hoping to see or something that you do not want but
is used with totally different output. Very much like having the same method
name in visible namespace structures (which actually gives compile error,
and intellisense shows it as read dot in front). In that condition you will
have to fully qualify it to avoid any error. If just using higher namespace
structure solves the problem then there will be lots of name collision which
will defeat the real purpose behind namespacing.

That is the base idea behind namespacing anyways, to avoid collisions while
naming.
 
You didn't read my post properly - I didn't change the code to
protected OleDbConnection oleDbConnection1;
protected OleDbDataAdapter oleDbDataAdapter2;
I changed it to
protected OleDb.OleDbConnection oleDbConnection1;
protected OleDb.OleDbDataAdapter oleDbDataAdapter2;
 
I see.
So I can put
System.Data.OleDb.OleDbConnection oleDbConnection1;
or I can put
using System.Data.OleDb
OleDbConnection oleDbConnection1;
but I can't put
using System.Data
OleDb.OleDbConnection oleDbConnection1;

I suppose it makes a sort of sense - it avoids a clash if two namespaces
both contain namespaces with the same name. But then it's only the same clash
that would happen if two namespaces contain objects with the same name. At
the end of the day, 'using' is a convenient shorthand, but if clashes occur
you have to fully specify, so why not allow a partial specification - if
there's no clash you're OK, and if there is a clash you're no worse off, you
just have to specify more precisely.

It must be the same in C++ but oddly I never hit it before.
--
Dave


Pohihihi said:
In addition to what Mattias said,

if using System.Data should make your statement work then question is just
by writing System every thing should work,

e.g.
using System;
....
....
OleDbConnection oleDbConnection1

it should create a object too, right? After all it is some place inside
System namespace.

Actually, it do not work like that. Reason is that using makes methods,
interface, and other stuff inside that namespace visible but not a namespace
in side it for inline use. One of the reason I can think of is that I can
have my own namespace named to be OleDB and it could have all the stuff
other than what you are hoping to see or something that you do not want but
is used with totally different output. Very much like having the same method
name in visible namespace structures (which actually gives compile error,
and intellisense shows it as read dot in front). In that condition you will
have to fully qualify it to avoid any error. If just using higher namespace
structure solves the problem then there will be lots of name collision which
will defeat the real purpose behind namespacing.

That is the base idea behind namespacing anyways, to avoid collisions while
naming.
Click to expand...
 
partial specification !!
well think this way, what if by hard luck all my namespaces, methods,
interface etcs under a xyz namespace are matching with your namespace abc.
Will you be willing to specify each function etc ? I will not. Basically it
makes life easy, in fact very easy.

--
Po

Dave said:
I see.
So I can put
System.Data.OleDb.OleDbConnection oleDbConnection1;
or I can put
using System.Data.OleDb
OleDbConnection oleDbConnection1;
but I can't put
using System.Data
OleDb.OleDbConnection oleDbConnection1;

I suppose it makes a sort of sense - it avoids a clash if two namespaces
both contain namespaces with the same name. But then it's only the same
clash
that would happen if two namespaces contain objects with the same name. At
the end of the day, 'using' is a convenient shorthand, but if clashes
occur
you have to fully specify, so why not allow a partial specification - if
there's no clash you're OK, and if there is a clash you're no worse off,
you
just have to specify more precisely.

It must be the same in C++ but oddly I never hit it before.
Click to expand...
 
Dave said:
I see.
So I can put
System.Data.OleDb.OleDbConnection oleDbConnection1;
or I can put
using System.Data.OleDb
OleDbConnection oleDbConnection1;
but I can't put
using System.Data
OleDb.OleDbConnection oleDbConnection1;

I suppose it makes a sort of sense - it avoids a clash if two namespaces
both contain namespaces with the same name. But then it's only the same clash
that would happen if two namespaces contain objects with the same name.
Click to expand...

One of those things, I think, where any increase in convenience would be
outweighed by the increase in complexity. The way it currently works
makes it very explicit and concise.

You can access member namespaces of an aliased namespace, though:

using Data = System.Data;
Data.SqlClient.SqlCommand cmd = new Data.SqlClient.SqlCommand();

I don't think I like that very much, I have to say.
 
You didn't read my post properly
Click to expand...

Yes I did.

- I didn't change the code to
protected OleDbConnection oleDbConnection1;
protected OleDbDataAdapter oleDbDataAdapter2;
Click to expand...

I know you didn't - I did, to show you a working alternative solution.

The "partial specification" feature you're asking for is how Imports
works in VB.NET, but not how using works in C#.



Mattias
 
Back
Top