Adding namespace/classes to an existing namespace

Rhodan

Active member
Joined
Apr 7, 2015
Messages
41
Programming Experience
10+
I'm probably searching with the wrong terms or maybe just not recognizing the answer when I see it.

I've got existing namespaces like

TheHardware.I2C

And I want to add classes to I2C like this

TheHardware.I2C.Devices

Then eventually like

TheHardware.I2C.Devices.Temperature
TheHardware.I2C.Devices.Pressure
etc.

But VS doesn't like when I add on to the existing I2C namespace. If I just use

TheHardware.Devices

Everything is fine and my classes show up. I don't want to add to the I2C source file directly and instead add a new file for each device.

What is this called that I'm trying to do so I can search and actually get results?

Thanks!
 
Actually I just realized something. I'm thinking of I2C as a namespace when it's actually a class inside TheHardware. That's probably the root of my problems.
 
Yep. For some reason my brain just can't figure these things out until I write it out in a post then a couple of minutes later I've figured it out.

I added a namespace I2C and renamed the I2C class to I2CCmd. Now I can add namespaces and classes the way I wanted to.
 
Ooh, I do have a real related question!

When I've added a child namespace as above (I2CCmd) I have to preface the actual commands (I2CReadByte() etc) with the class name. I want to get around having the double I2C bit I2CCmd.I2CReadByte() which I could do by making each actual command a class on it's own but I'm wondering if there's a less typing intensive way? So that when I've said "using MyNameSpace.I2C" I can just use I2CReadByte() without having a separate class for it?

Hope that makes sense.
 
You seem to have some strange ideas about what namespaces, classes and methods actually are. A class is a description of a type. In simple terms, a type can have data (properties) and behaviour (methods). Behaviour doesn't just exist in and of itself, without a type to actually behave that way, so your request to have methods that are not part of a class makes no sense.

Namespaces are simply a way to logically group related types together. For instance, the System.Data namespace contains all the types in the .NET Framework related to general data access while the System.Data.SqlClient contains all the types related to data access specific to SQL Server and System.Data.OleDb contains all the types related to data access for OLE DB data sources. Namespaces don't exist in an of themselves; a namespace only exists if there exists a type that is a member of it. As I said, namespaces are logical groupings of types. That means that the same namespace can be spread across multiple assemblies if those assemblies each contain the declaration of a type that is a member of that namespace.

In your case, if you have a method named I2CReadByte then it must be a member of a type and that type must be a member of a namespace. If you want to avoid having I2C everywhere then stop putting it everywhere. If you have a namespace named MyNameSpace.I2C then does a type in that namespace really have to be named I2CCmd? Why can't it just be named Command or Commands or whatever else is appropriate? If it's already in a namespace that exists to group all the types related to I2C, why do you need I2C in the name of the type? That goes doubly for the method, i.e. why call it I2CReadByte rather than just ReadByte? If it's a member of a type that is a member of a namespace that you know is specifically for I2C functionality, why do you need I2C in the name of the method, especially if it's in the name of the type too?

That said, if you want to be able to avoid qualifying static members of a type then you can actually import the type. For instance, lets say that there exists a DoSomething method in the SomeType class in the SomeNamespace namespace. With no import, you'd need to call it like this:
SomeNamespace.SomeType.DoSomething();

If you import the namespace then you don't have to qualify the type:
using SomeNamespace;

'...

    SomeType.DoSomething();

If you import the type then you don't have to qualify the method:
using static SomeNamespace.SomeType;

'...

    DoSomething();

I would recommend caution though. Personally, I would only do that if I was making a lot of static calls and not much else. Otherwise, it makes it less clear what belongs to what. Intellisense means that qualifying methods with their type is hardly onerous.
 
Back
Top Bottom