Creating Your own Namespace...

  • Thread starter Thread starter Simon Edwards
  • Start date Start date
S

Simon Edwards

Something thats been bugging me for a while...

how do you create a namespace that has many children (namespaces)

I.e system.io.blah.blah

Iv'e done it by creating a class which contains another class.

i can see the properties of the first class and the namespace of the second
(inner class) but can't see the properties of the 2nd....

This might not have been put very well............
 
Thus spake Simon Edwards:
how do you create a namespace that has many children (namespaces)

Just specify the desired namespace in each file:

(File A)
namespace MyUtilityLibrary.Data

(File B)
namespace MyUtilityLibrary.Data.Sql
 
Ok i've put something together as an example...

Public Class Test1

Public ReadOnly Property test1_prop()

Get

End Get

End Property

Public Class Test2

Public ReadOnly Property test2_prop()

Get

End Get

End Property

End Class

End Class



The above when insntaned will let you see the test1 property and the test 2
class but not thye test2 property?

i want to build my own classes with a structure similar to how dot net works
with its namespaces

(e-mail address removed)> wrote in message
 
Hello,

Simon Edwards said:
how do you create a namespace that has many children
(namespaces)

I.e system.io.blah.blah

Iv'e done it by creating a class which contains another class.

i can see the properties of the first class and the namespace of the second
(inner class) but can't see the properties of the 2nd....

This might not have been put very well............

\\\
Namespace Bla
Namespace Foo
...
End Namespace

Namespace Gac
...
End Namespace
End Namespace

Namespace Moo
...
End Namespace

Namespace Moo.Baz
...
End Namespace

Namespace Moo.Goo
...
End Namespace
///
 
Thus spake Simon Edwards:
i want to build my own classes with a structure similar to how dot
net works with its namespaces

Your example shows nested classes, not namespaces. Typically, a nested
class is meant for use only within its parent class. Namespaces are
simply organizational units.

Let's say you have a console application project with three files. The
first one we'll leave alone. In the second one, change the namespace to
MyConsoleApp.Blah. in the third one, change the namespace to
MyConsoleApp.Blah.Blah.

Now go back to the first file and add a pair of using directives:

using MyConsoleApp.Blah;
using MyConsoleApp.Blah.Blah.

See how the IntelliSense pops out? Now that you have multiple
namespaces, you can use them to organize your classes as you see fit.
 
Hello,

Simon Edwards said:
Ok i've put something together as an example...

Public Class Test1

Public ReadOnly Property test1_prop()

Get

End Get

End Property

Public Class Test2

Public ReadOnly Property test2_prop()

Get

End Get

End Property

End Class

End Class



The above when insntaned will let you see the test1
property and the test 2 class but not thye test2 property?

i want to build my own classes with a structure similar to
how dot net works with its namespaces

Classes are different from namespaces. Are you sure you understand the
difference between them? If you don't understand it, I would suggest to
have a quick look at the VB.NET documentation. Your sample shows a
declaration of a class inside a class, this has nothing to do with
namespaces.
 
Hi Simon,

Namespaces are for differentiating between classes (and other entities)
which have the same name.

Consider:
Namespace Edwards
Class Simon
End Class
End Namespace

Namespace Jones
Class Simon
End Class
End Namespace

Now, somewhere else, I want to create an instance of a Simon.
Dim MyMan As Simon

This will fail, however, - the compiler complaining that there is a choice
of two.

I have to qualify it with the appropriate namespace.
Dim MyMan As Edwards.Simon

This will work and that, simplified, is what namespaces are for.

===============================
Nested classes are for when you need the facilities that a class provides
but only for the exclusive use of the outer class. This is not as common a
situation as you seem to be implying. Usually the inner class will be Private
or Protected. If it is going to be Public, there's little point in having it
nested.

Public Class clsOuter
Public OuterField As New clsInner
Public Class clsInner
Public InnerField As Integer = 3
End Class
End Class

Somewhere you declare an instance of the outer class:
Dim oFoo As clsOuter

This will create an instance of clsInner for itself and that will set its
InnerField to 3.

With oFoo you can access OuterField but not InnerField.
With oFoo.OuterField you can access InnerField.

===============================
Usually you have the inner class as Private and expose it indirectly using
Properties.

Public Class clsOuter
Private MyInner As New clsInner
Public ReadOnly Property OuterProp As Integer
Get
Return MyInner.InnerField
End Get
End Property
Private Class clsInner
Public InnerField As Integer = 3
End Class
End Class

Somewhere you declare an instance of the outer class:
Dim oFoo As clsOuter

This will again create an instance of clsInner for itself whiich will set
its InnerField to 3.

With oFoo you can only access OuterProp which will give you InnerField's
value.

===============================
I'm intrigued - can you tell us more about this hierarchy that you want to
build ?

Regards,
Fergus
 
I am only using C#, but I assume this works the same way in VB.NET; The
answer applies to projects in visual studio.net.

You may change the default namespace of your project by using the properties
on the project; right-click the project-name, select "properties", find
"default namespace". Here you may want to change from the "project-name"
(which is the normal) to "company.project" or something.

Further, by creating subdirectories in the project folder, the namespace for
new elements will default to the default namespace-name of elements in the
parent directory + the name of the directory.

You may also change the namespace manually using the namespace-statement;
this is what automatically happens using the methods mentioned above.

What I think would be normal with regards to namespace; would be to make
library-projects with sensible namespaces for what library it is;
company.controls.winforms company.net.smtp; and such; and in the main
program just use the default namespace. You may want to subdivide some
libraries, then you would use folders to create new namespaces.

Regards,

Harald Bjorøy
www.ulriken-consulting.no
 
Back
Top