By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,302 Members | 1,788 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,302 IT Pros & Developers. It's quick & easy.

How to understand the use of namespaces ...

P: n/a
Using 2.0 with Master Pages and a GlobalBaseClass for the content pages.

I understand the easy part -- the hierarchical structure of a namespace
naming convention -- but the 2.0 IDE does not write a signature for the
developer and after getting a good start developing a 2.0 application I
thought I should go through the code and start marking classes and with
namespaces. I keep getting the following 'missing' error even when using a
first level namespace in the base class for example as well as other classes
such as the partial class and utility classes I have written.

// Error
The type or namespace name 'GlobalBaseClass' could not be found (are you
missing a using directive or an assembly reference?)

So if I try this first level signature...

namespace CompanyName
{
....
}

The 'missing' error occurs.

I have at least two dozen instance of partial classes already and four of
my own utility classes. Is the first level CompanyName namespace required in
each and every class? These are the sorts of issues that remain murky in my
muddled mind.

Can somebody explain or provide a URL to a blog or tutorial that really gets
into where and when the compiler wants namespaces declared?

<%= Clinton Gallagher
Nov 17 '05 #1
Share this Question
Share on Google+
17 Replies


P: n/a
"clintonG" <cs*********@REMOVETHISTEXTmetromilwaukee.com> wrote in message
news:uK**************@TK2MSFTNGP15.phx.gbl...
Using 2.0 with Master Pages and a GlobalBaseClass for the content pages.

I understand the easy part -- the hierarchical structure of a namespace
naming convention -- but the 2.0 IDE does not write a signature for the
developer and after getting a good start developing a 2.0 application I
thought I should go through the code and start marking classes and with
namespaces. I keep getting the following 'missing' error even when using a
first level namespace in the base class for example as well as other
classes such as the partial class and utility classes I have written.

// Error
The type or namespace name 'GlobalBaseClass' could not be found (are you
missing a using directive or an assembly reference?)

So if I try this first level signature...

namespace CompanyName
{
...
}

The 'missing' error occurs.

I have at least two dozen instance of partial classes already and four of
my own utility classes. Is the first level CompanyName namespace required
in each and every class? These are the sorts of issues that remain murky
in my muddled mind.

Can somebody explain or provide a URL to a blog or tutorial that really
gets into where and when the compiler wants namespaces declared?

<%= Clinton Gallagher


It appears that the type GlobalBaseClass is not resolvable by the compiler.
Its telling you exactly what the issue is: either you don't have a reference
to the assembly that contains GlobalBaseClass or you do but its in a
namespace that you don;t ave a using statement for - or maybe both.

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk
Nov 17 '05 #2

P: n/a
Hi Clinton,

each class which will use a class from another
than it's own namespace this namespace have to
be add.

e.g.

##start
using MyNamespace1;
using MyNamespace2;

namespace MyNamespace3
{
//here you can use classes from the namespaces
//MyNamespace1, MyNamespace2
}
##end

Please notice, that if the namespace you have to use is in an seperate
dll, you have to add them to your project references.
Using mean only using not reference the dll's.

Hope that helps ;)

Cheers
Lars Behrmann

_________________
Nothing is impossible. UML is the key for all your problems.
AODL - Make your .net apps OpenOffice ready
http://aodl.sourceforge.net/

clintonG schrieb:
Using 2.0 with Master Pages and a GlobalBaseClass for the content pages.

I understand the easy part -- the hierarchical structure of a namespace
naming convention -- but the 2.0 IDE does not write a signature for the
developer and after getting a good start developing a 2.0 application I
thought I should go through the code and start marking classes and with
namespaces. I keep getting the following 'missing' error even when using a
first level namespace in the base class for example as well as other classes
such as the partial class and utility classes I have written.

// Error
The type or namespace name 'GlobalBaseClass' could not be found (are you
missing a using directive or an assembly reference?)

So if I try this first level signature...

namespace CompanyName
{
...
}

The 'missing' error occurs.

I have at least two dozen instance of partial classes already and four of
my own utility classes. Is the first level CompanyName namespace required in
each and every class? These are the sorts of issues that remain murky in my
muddled mind.

Can somebody explain or provide a URL to a blog or tutorial that really gets
into where and when the compiler wants namespaces declared?

<%= Clinton Gallagher


Nov 17 '05 #3

P: n/a
I think you should start by understanding that there is no such thing as a
namespace in .NET

While classes may contain dots and while Visual Studio and languages like C#
uses these dots to create groups of classes there are actually only
assemblies containing classes and references to assemblies you actually work
with.

Happy Coding
- Michael S

ps.
I left out a couple of , and . in hope that some people would faint while
reading the above out loud.
Nov 17 '05 #4

P: n/a
MUS
Hello Clinton !

You need to keep an eye on matter that "namespace" and "assembly" are
not related to each other in any way (It was used to be a case in Java
where package was strongly binded to the file structure but not here in
..Net).

Various types (classes) belonging to a particular namespace might be
implemented in multiple assemblies. For example
"System.Collections.ArrayList" type is in "mscorlib.dll" assembly and
the "System.Collections.StringCollection" type is in "system.dll"
assembly. So you see here "System.Collections" namespace is spaned
across two assemblies "mscorlib.dll" and "system.dll"

On the contrary, a single assembly can contain types belonging to
heterogeneous namespaces. For example "System.Int32" and
"System.Collections.ArrayList" types are both in "mscorlib.dll". Here
"mscorlib.dll" contains both the "System" namespace as well as the
"System.Collections" namespace.

If you go through MSDN you will notice that the documentation expressly
specify:
1) The namespace that the type belongs to i.e. "ArrayList" type belongs
to namespace "System.Collections", and
2) Which assembly contains the type i.e. "mscorlib.dll" contains
"System.Collections.ArrayList"

So what you need to do is to statically reference the assembly that
contains the type and then in your code use the FQN (Fully Qualified
Name i.e. <namespace>.<type>)

I hope this might be of some help.

Let me know in case of any inconsistancy.

Regards,

Moiz Uddin Shaikh
Software Engineer
Kalsoft (Pvt) Ltd

Nov 17 '05 #5

P: n/a
<snip />

I've been down in the dumps the last couple days but hello,. I'm back, and I
thank all who chose to comment and provide some insight. I'll take each
comment and work with it while doing more study of this topic.

<%= Clinton Gallagher
Nov 17 '05 #6

P: n/a
> Various types (classes) belonging to a particular namespace might be
implemented in multiple assemblies.
This is true.
For example "System.Collections.ArrayList" type is in "mscorlib.dll" assembly and
the "System.Collections.StringCollection" type is in "system.dll"
assembly. So you see here "System.Collections" namespace is spaned
across two assemblies "mscorlib.dll" and "system.dll"


This is a bad example. ArrayList is in the System.Collections
namespace, while StringCollection is in System.Collections.Specialized.

In .NET, exactly as in Java, the apparent "hierarchy" of namespaces
isn't a hierarchy at all; it's a human convention that means nothing to
the compiler. For example, the compiler sees "System.Collections" and
"System.Collections.Specialized" as two separate namespace names that
have nothing to do with each other. The fact that, as human beings, we
recognize that the second adds ".Specialized" onto the end of the
first, and it looks like a member selection with that "." there, holds
no sway with the compiler, which just says, "System.Collections" !=
"System.Collections.Specialized" and so they're two completely
different, independent namespaces.

..NET namespaces differ from Java namespaces in other ways, but this
isn't one of them: both platforms have what looks like a hierarchical
namespace model but isn't.

Nov 17 '05 #7

P: n/a
Hello Moiz,

That was very well said but still as we say, 'clear as mud.' I'm used to
pages, not assemblies. I'm used to types as some value such as an integer,
not as a class, so I'm still working on internalizing my understanding of
these OOP fundamentals as applied to .NET.

What I thought I could do is use the concept of 'namespace CompanyName' in
the partial class for a page. When I tried to do so in a single page the
compiler started yelling at me. I thought I could -- or should -- also use a
construct such as 'namespace CompanyName.ProductType.ProductName' in
specific pages so I could somehow access members in that page -- class --
from other classes using dotted notation to access the members understand
that I would have to have a using CompanyName.ProductType.ProductName
statement as Lars discussed.

Then in my code I would use

using CompanyName.ProductType.ProductName;

ProductName pn = new ProductName( );
pn.SomeMember.SomeProperty = value;

All of a sudden I remember if I said it that way the compiler would yell at
me to tell me I was trying to use a class as a method.

Just writing that out helps me understand that I am still confusing some OOP
principles. I don't have a clue right now how to sort it out and need to get
a fundamental understanding of how this concept of namespace is used in a
web application. Perhaps more importantly, why I should be using namespaces
and what benefit they provide in a web application.

Now if I had server controls I had created I think it would start to make
more sense as your example seems to imply as I would not be able to get or
set the value of a property of a class named 'color' for example which may
be a member of more than one class in the same dll. That's another
presumption what I think I understand about this topic, i.e. avoid conflicts
when members share the same name or type.

Is that enough for you to fix up my flawed understanding?

<%= Clinton Gallagher

"MUS" <mo********@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...
Hello Clinton !

You need to keep an eye on matter that "namespace" and "assembly" are
not related to each other in any way (It was used to be a case in Java
where package was strongly binded to the file structure but not here in
.Net).

Various types (classes) belonging to a particular namespace might be
implemented in multiple assemblies. For example
"System.Collections.ArrayList" type is in "mscorlib.dll" assembly and
the "System.Collections.StringCollection" type is in "system.dll"
assembly. So you see here "System.Collections" namespace is spaned
across two assemblies "mscorlib.dll" and "system.dll"

On the contrary, a single assembly can contain types belonging to
heterogeneous namespaces. For example "System.Int32" and
"System.Collections.ArrayList" types are both in "mscorlib.dll". Here
"mscorlib.dll" contains both the "System" namespace as well as the
"System.Collections" namespace.

If you go through MSDN you will notice that the documentation expressly
specify:
1) The namespace that the type belongs to i.e. "ArrayList" type belongs
to namespace "System.Collections", and
2) Which assembly contains the type i.e. "mscorlib.dll" contains
"System.Collections.ArrayList"

So what you need to do is to statically reference the assembly that
contains the type and then in your code use the FQN (Fully Qualified
Name i.e. <namespace>.<type>)

I hope this might be of some help.

Let me know in case of any inconsistancy.

Regards,

Moiz Uddin Shaikh
Software Engineer
Kalsoft (Pvt) Ltd

Nov 17 '05 #8

P: n/a
I'm tuning in on your comments Bruce but if this 'convention' is simply a
human convention why does the compiler even give a rat's @ss?

For the sake of consistent and collaborative discussion which may cross from
one thread into another would you pick a relevant namespace from the Class
Browser [1] so we can all stay on the same page so to speak?

One thing I have yet to figure out then is how to know which assembly the
System.Collections.ArrayList class would belong to? How are we to know it
would be mscorlib.dll when the Class Browser does not make this evident? Are
we compelled to use a tool such as Ildasm or Roeder's Reflector to determine
which assembly the class is located within? What is the context doing so
becomes most useful?

Broadly speaking then, I would not consider System.Collections [1] to be a
bad example after all as it certainly helps one understand how certain
assemblies are distributed throughout the framework when they share the same
namespace. I feel an epiphany coming on as it now seems I am beginning to
understand what you meant by 'human convention' as these namespace names are
not to be understood literally but as generalized references to some things
that are associated with the general reference -- classes -- which can be
referred to by humans using a common terminology that by convention we agree
to call a namespace.

Finally, why does Microsoft insist on confusing the clueless like me by
doing this without sending me a letter to let me know? ;-) Why do they use
the term hierarchy in the Class Browser when it is apparently a human
convention? I'm formally educated and trained as an architect so when I read
documentation I expect to interpret what I read as a literal conveyance of
fact derived from the science of the context of the topic.

<%= Clinton Gallagher

[1]
http://beta.asp.net/QuickStartv20/ut...em.Collections

"Bruce Wood" <br*******@canada.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
Various types (classes) belonging to a particular namespace might be
implemented in multiple assemblies.


This is true.
For example "System.Collections.ArrayList" type is in "mscorlib.dll"
assembly and
the "System.Collections.StringCollection" type is in "system.dll"
assembly. So you see here "System.Collections" namespace is spaned
across two assemblies "mscorlib.dll" and "system.dll"


This is a bad example. ArrayList is in the System.Collections
namespace, while StringCollection is in System.Collections.Specialized.

In .NET, exactly as in Java, the apparent "hierarchy" of namespaces
isn't a hierarchy at all; it's a human convention that means nothing to
the compiler. For example, the compiler sees "System.Collections" and
"System.Collections.Specialized" as two separate namespace names that
have nothing to do with each other. The fact that, as human beings, we
recognize that the second adds ".Specialized" onto the end of the
first, and it looks like a member selection with that "." there, holds
no sway with the compiler, which just says, "System.Collections" !=
"System.Collections.Specialized" and so they're two completely
different, independent namespaces.

.NET namespaces differ from Java namespaces in other ways, but this
isn't one of them: both platforms have what looks like a hierarchical
namespace model but isn't.

Nov 17 '05 #9

P: n/a
Bruce Wood <br*******@canada.com> wrote:
In .NET, exactly as in Java, the apparent "hierarchy" of namespaces
isn't a hierarchy at all; it's a human convention that means nothing to
the compiler.


That's not *quite* true for C# - because any "parent" namespaces are
already in scope. In other words, if I'm writing code in namspace
Foo.Bar.Baz, then there's effectively statements:

using Foo;
using Foo.Bar;

already. This isn't true in Java.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 17 '05 #10

P: n/a
MUS
Hello Bruce!

Well thanks Bruce for pointing out my mistake, my apologize for the
inconvenience.

Well let me replace my faulty illustration with a few which will map to
the discoursed scenario:

1) "System.Web" namespace is spanned across 2 assemblies "System.dll"
and "System.Web.dll"

2) Also, "System.Security" namespace is spanned across "mscorlib.dll"
and "System.Security"

Concepts of "namespaces" in .NET is a "logical" construct rather than a
"physical & logical" as in Java

By physical, i mean, Packages are the way we organize our files into
different directories according to their functionality and usability.

Logical in the sense that Packaging help us to avoid class name
collision when we use the same class name as that of others. For
example, if i want to have a class name "Vector", its name would crash
with the "Vector" class from Collection Framework.

I think CliontG, by now, would have got the idea how to tacke
namespaces and assebmlies.

If still there is anything, i am all ears.

Regards,

Moiz Uddin Shaikh
Software Engineer
Kalsoft (Pvt) Ltd

Nov 17 '05 #11

P: n/a
<snip />

Yes, clintonG thinks so too. :-)
Nov 17 '05 #12

P: n/a
Thanks, Jon. I learn something new every day here. :-)

Nov 17 '05 #13

P: n/a
Just to clarify, Jon, it is _not_ true that saying

using Foo.Bar;

means that the Foo namespace is also in scope, right? If I'm coding in
namespace Hose and I want both Foo.Bar and Foo, I believe that I have
to say

using Foo;
using Foo.Bar;

However, I'm open to being corrected.

Nov 17 '05 #14

P: n/a
Bruce Wood <br*******@canada.com> wrote:
Just to clarify, Jon, it is _not_ true that saying

using Foo.Bar;

means that the Foo namespace is also in scope, right?
Correct.
If I'm coding in
namespace Hose and I want both Foo.Bar and Foo, I believe that I have
to say

using Foo;
using Foo.Bar;

However, I'm open to being corrected.


Nope, you're absolutely right. It's a special case for the namespace
the code you're writing is in.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 17 '05 #15

P: n/a
Here's my stab at explaining namespaces. I hope you find it useful.

The runtime pays scant attention to namespaces, as Michael S pointed
out. Every class has a rather long name, such as
System.Collections.ArrayList. That's the real name of the class, not
ArrayList, and in fact you can write all the references to classes
outside your current project that way, without ever writing a single
"using" directive. If you look at the code that the Forms Designer
generates, you'll see that it never defines just Label, for example. It
always generates code that says System.Windows.Forms.Label. (There's a
reason, which I'll mention later. For now, just notice that it's
perfectly valid to do this.)

However, for most of us, that would be horribly tedious: the code would
be longwinded and difficult to read.

So, the "using" directive comes to the rescue. I can "open up" a
namespace by saying,

using System.Collections;

and now when I mention "ArrayList", the compiler knows to look not only
in my own code, but also in all of the things with names starting with
"System.Collections." to see if it can find something called
"ArrayList". This makes the code a lot easier to read. Nonetheless, at
the end of the day all of the class names that the compiler generates
in the IL are all fully qualified: the compiler will write
System.Collections.ArrayList out the back end, no matter what.

This, however, is not the reason why namespaces were created. MUS
explained the motivation: there are people all over the world writing
reusable libraries. I don't want to be required to consult some
enormous, global dictionary of class names that people have already
used and avoid calling my classes by those names in case I want to use
someone else's library. What a disaster if I write my own code and then
later decide to plug in your library, and discover that there are 30
class names (or 300 class names) that I used in my code that you also
used in yours.

..NET and Java solve this problem by allowing each of us to "wrap" our
code in a namespace. Then all that we have to do is make sure that we
don't use the same namespace name. The Java convention was to always
use a URL in reverse. If you own the URL, then you're guaranteed that
nobody else will have the same namespace name. For example, if the
folks at Google were to write some search tools, they could wrap them
in namespace

namespace com.google.SearchTools
{
}

and be assured that nobody else in the world will have class names that
collide with theirs. (Remember that the true name of every class
defined within those curly braces would be "com.google.SearchTools...",
not just the name written in the class declaration.)

This is why the Forms Designer writes all class names as
fully-qualified. For all it knows, you may have defined a class called
Label in your form's namespace, and so if the Designer were to write
just "Label" then it runs the risk of creating an instance of one of
your classes, not of System.Windows.Forms.Label, so it plays it safe
and always uses the fully-qualified name, which is guaranteed to always
work.

So why does the Class View, among other things, present namespaces to
us as though they were hierarchies when in fact they aren't (with the
exception noted by Jon Skeet)? Only because it's convenient for us
think about them that way. It's a nice way to organize code, even if
the compiler, in the end, flattens the whole thing out and generates a
bunch of classes with really long names gathered into assemblies. Like
everything else in computing, it's about making it easier for us
programmers to organize and maintain our solutions. Don't forget that
everything we do gets boiled down to bits of data and machine code in
the end (and the machine doesn't even really make that distinction)...
everything other than binary code is there for our benefit, not the
computer's. Namespaces are just another example of that phenomenon.
One thing I have yet to figure out then is how to know which assembly the
System.Collections.ArrayList class would belong to?


Well, I'm not dab hand with the class browser... I hardly ever use
it... but the way it organizes what it shows to me is as a hierarchy:
projects containing namespaces, which can contain other namespaces,
which in turn contain classes, which contain fields, methods,
properties, etc.

I don't even know how to have the class browser show me the
organization of the Framework namespaces. Anyone?

I rely on the MSDN documentation for the Framework to tell me where a
class lives: the main "about" page for each class shows, near the
bottom, which DLL it lives in.

Nov 17 '05 #16

P: n/a
Well, Bruce, it's a little simpler than that. And you would be surprised
where namespaces crop up outside of the .Net Framework and Object-oriented
programming technologies. I'm pretty good with analogies, so I'm going to
start with one.

You're in an office building, and you have an appointment to speak with
someone who works in that building. So, you walk up to the information desk,
and say "I have an appointment to speak with a person." The person behind
the desk looks at you quizically, and says, "Well, that narrows it down to
about 400 people who happen to be in this building right now. You're
reference is ambiguous. I can't identify the person you want to speak to, so
I can't help you."

So, you step back, and you remember that it is a man that you want to speak
to. So, you walk back up to the information desk and say "It's a man I need
to speak to." The fellow behind the desk laughs, and says "Well, that
narrows it down to about 200 people. Sorry."

Suddenly, you remember the fellow's first name. It's John. "John!" you
shout. "I have an appointment with John!" Now, the fellow behind the desk
scratches his head. "Nope," he says. "That's an ambiguous name reference.
There are about 50 Johns in this building." Crestfallen, you step away again
to think.

After a minute, you remember his last name. It's Smith. And then you
remember that he is in the accounting department. So, you walk confidently
to the information desk again. "His name is John Smith, and he's in the
accounting department." Now, the fellow behind the desk starts leafing
through a directory. "The accounting department is floors 7 and 8, and there
are 4 John Smiths in that department" he finally replies.

Well, that's enough for you to go and start looking for yourself. So, you
take the elevator up to the 7th floor, and start walking around, asking
everyone where "John Smith" is. But everyone replies in the same way: "Which
John Smith do you want to talk to?" You finally reply, "Any John Smith will
do. Just point me to his office."

So, after being directed to one wrong John Smith's office on the 7th floor,
and 2 wrong John Smith's offices on the 8th floor, you finally find the
right one. Of course, you're too late for your appointment. He tells you
you'll have to schedule another one for tomorrow. On your way out, you take
note of the sign on his door: "Mr.John.Smith.Accountant.Room714." And you
make sure to write it down.

When you get home, your wife is waiting for you. You don't see your son
around, so you ask her, "Where's John?" She replies, "he went to the grocery
store."

Now, why did the information desk clerk have so much trouble telling you
where to find an accountant named John Smith, but when you got home, you
simply asked where "John" was, and your wife knew exactly what and whom you
were talking about? Well, it's all about context.

The CLR, and almost any body of classes, is going to have quite a few
members in it. Class names and member names are usually designed to make
sense to humans, but it is almost inevitable that some class names, or other
types of member names, are going to be the same as some other member of
something somewhere else. Depending on the context, or scope of the
situation, it might be easier to make the distinction.

So, you start a project, and you add a reference to 2 different DLLS in your
project. These are 2 completely different DLLs, but they have some classes
in them with the same name as in the other DLL. In your code, so that you
don't have to write out the full namespace of the assembly in which the
different classes reside, you add the following:

using foo;
using bar;

foobar theFoo = new foobar();

Suddenly, you get a compiler exception: Ambiguous name reference. You see,
the foo assembly has a class named foobar, and so does the bar assembly. How
does the compiler know which one your code is referring to? Well, you want
the foo version, so you change your code:

foo.foobar theFoo = new foobar();

Suddenly, the sun comes out, and everything is fine again. But let's look at
another possibility:

using foo;

foobar theFoo = new foobar();

No exception is thrown. Why? Because you didn't add the "using bar;"
statement. To reference bar.foobar you would have to use the full namespace,
as the compiler would have no context to identify the class. The compiler
has to know at all times the exact address of the member referenced.
sometimes it can infer it from the context:

public class foo
{
public string bar = "foobar";

public string foobar()
{
return bar;
}
}

Of course, it could read:

public string foobar()
{
return this.bar;
}

But as the function exists in the context of the class foo, the compiler can
infer the namespace of the address of the field.

In other words, a namespace is a way of defining a unique ADDRESS of
something in memory. You and I see code in a file. The application, once
compiled, sees addresses in memory. The compiler can infer some of them
during compilation, which involves the assignment of the addresses of code.
But there has to be a mechanism for uniquely idenfying others in your code,
so that the compiler can correctly discern which address belongs to what
token in your code.

Why are namespaces hierarchical? For purposes of easy organization. A
hierarchy is a tree, like a postal address. Consider the following postal
address:

13 Mockingbird Lane, Anytown, USA

The address becoms more specific from right to left. "USA" eliminates all
addresses outside of the U.S. "Anytown" eleminates all address outside the
U.S., and outside "Anytown" IN the U.S. "Mockingbird Lane" further
eliminates any address not on Mockingbird Lane. And 13 uniquely identifies
that house on that street. 13 by itself does nothing. Most streets have an
address of 13. Mockingbird Lane does nothing by itself either. Many cities
and towns have a Mockingbird Lane. And so on. But by successively elminating
branches of the "tree" you narrow it down in short order to a single unique
address. If the Earth is the tree, countries are the immediate branches,
cities are branches off of those, streets are branches off of city branches,
and the numbers are the individual leaves on those branches. a hierarchical
(or tree) structure is the most efficient means of uniquely identifying
anything in any type of organization.

Hope that makes things a bit clearer.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.
"Bruce Wood" <br*******@canada.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...
Here's my stab at explaining namespaces. I hope you find it useful.

The runtime pays scant attention to namespaces, as Michael S pointed
out. Every class has a rather long name, such as
System.Collections.ArrayList. That's the real name of the class, not
ArrayList, and in fact you can write all the references to classes
outside your current project that way, without ever writing a single
"using" directive. If you look at the code that the Forms Designer
generates, you'll see that it never defines just Label, for example. It
always generates code that says System.Windows.Forms.Label. (There's a
reason, which I'll mention later. For now, just notice that it's
perfectly valid to do this.)

However, for most of us, that would be horribly tedious: the code would
be longwinded and difficult to read.

So, the "using" directive comes to the rescue. I can "open up" a
namespace by saying,

using System.Collections;

and now when I mention "ArrayList", the compiler knows to look not only
in my own code, but also in all of the things with names starting with
"System.Collections." to see if it can find something called
"ArrayList". This makes the code a lot easier to read. Nonetheless, at
the end of the day all of the class names that the compiler generates
in the IL are all fully qualified: the compiler will write
System.Collections.ArrayList out the back end, no matter what.

This, however, is not the reason why namespaces were created. MUS
explained the motivation: there are people all over the world writing
reusable libraries. I don't want to be required to consult some
enormous, global dictionary of class names that people have already
used and avoid calling my classes by those names in case I want to use
someone else's library. What a disaster if I write my own code and then
later decide to plug in your library, and discover that there are 30
class names (or 300 class names) that I used in my code that you also
used in yours.

.NET and Java solve this problem by allowing each of us to "wrap" our
code in a namespace. Then all that we have to do is make sure that we
don't use the same namespace name. The Java convention was to always
use a URL in reverse. If you own the URL, then you're guaranteed that
nobody else will have the same namespace name. For example, if the
folks at Google were to write some search tools, they could wrap them
in namespace

namespace com.google.SearchTools
{
}

and be assured that nobody else in the world will have class names that
collide with theirs. (Remember that the true name of every class
defined within those curly braces would be "com.google.SearchTools...",
not just the name written in the class declaration.)

This is why the Forms Designer writes all class names as
fully-qualified. For all it knows, you may have defined a class called
Label in your form's namespace, and so if the Designer were to write
just "Label" then it runs the risk of creating an instance of one of
your classes, not of System.Windows.Forms.Label, so it plays it safe
and always uses the fully-qualified name, which is guaranteed to always
work.

So why does the Class View, among other things, present namespaces to
us as though they were hierarchies when in fact they aren't (with the
exception noted by Jon Skeet)? Only because it's convenient for us
think about them that way. It's a nice way to organize code, even if
the compiler, in the end, flattens the whole thing out and generates a
bunch of classes with really long names gathered into assemblies. Like
everything else in computing, it's about making it easier for us
programmers to organize and maintain our solutions. Don't forget that
everything we do gets boiled down to bits of data and machine code in
the end (and the machine doesn't even really make that distinction)...
everything other than binary code is there for our benefit, not the
computer's. Namespaces are just another example of that phenomenon.
One thing I have yet to figure out then is how to know which assembly the
System.Collections.ArrayList class would belong to?


Well, I'm not dab hand with the class browser... I hardly ever use
it... but the way it organizes what it shows to me is as a hierarchy:
projects containing namespaces, which can contain other namespaces,
which in turn contain classes, which contain fields, methods,
properties, etc.

I don't even know how to have the class browser show me the
organization of the Framework namespaces. Anyone?

I rely on the MSDN documentation for the Framework to tell me where a
class lives: the main "about" page for each class shows, near the
bottom, which DLL it lives in.

Nov 17 '05 #17

P: n/a
Thanks for point out the bit about collisions if you specify multiple
"using" directives that open two or more namespaces that contain items
with the same names. By the way, you get the error message only if you
use one of the colliding names in your code: you can have "using"
directives for two namespaces that contain the same name, but if you
don't actually use that name anywhere in your code, your code will
compile clean (under C#, at least).
Of course, it could read:

public string foobar()
{
return this.bar;
} But as the function exists in the context of the class foo, the compiler can
infer the namespace of the address of the field.
I could be wrong (I often am), but so far as I know the "this" keyword
isn't a namespace. It's an object reference.
In other words, a namespace is a way of defining a unique ADDRESS of
something in memory.
Not as I understand namespaces, memory, and the CLR. A namespace is
little more than a notational convenience that the compiler supplies so
that it's easier to write code with unique class (and other top-level)
names. The only relationship I can see to addresses is an indirect one:
the namespace in which a class is defined is used to build up its full
(true) name, and that full name is what the CLR sees. The JITter
produces actual machine code, which finally nails things down to memory
addresses, and at that point the only remnants left of namespaces are
the fully-qualified names of the things being instantiated.

If you mean that the namespace contributes to the unique identity of a
class or other top-level item in your assembly, then I would agree, but
relating that to memory addresses is, IMHO, wide of the mark.
You and I see code in a file. The application, once compiled, sees addresses in memory.
The compiler can infer some of them during compilation, which involves the assignment of the addresses of code.
But there has to be a mechanism for uniquely idenfying others in your code,
so that the compiler can correctly discern which address belongs to what token in your code.


Sorry, you lost me. The .NET compilers don't assign hard memory
addresses to anything. They generate IL (intermediate language), which
is then JITted to machine code on demand at runtime. Traditional,
direct-to-machine-code compilers do something like what you describe,
but so far as I know in .NET it happens long after the compiler has
done its job.

Nov 17 '05 #18

This discussion thread is closed

Replies have been disabled for this discussion.