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.
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?
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.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.