can I expose a class from another .net namespace as a class in my namespace?

Question

Can I expose a class from another .net namespace as a class in my namespace? I use a class - antlr.collections.AST - as the return type for a function belonging to a class in my namespace; as a result, the user has to have

using antlr.collections;
using myNamespace;

at the top of their files in order to use my function. Can I make myNamespace.AST an alias for antlr.collections.AST, such that the user only has to have

using myNamespace;

at the top of their files?

Answer 1

How about deriving a class using the same name in the new namespace? I meant:

namespace MyForms {
    class Class1 : Some.Other.Namespace.Class1 {
        // ...
    }
}

Answer 2

No, you can't.

The full path to and name of a class is part of its identity.

Answer 3

create a new class that inherits the class in your new namespace. It's not ideal, but it's useful for unit testing and the like.

You should think about why you are doing this though, classes are broken up into namespaces for a reason.

Answer 4

Bear in mind that the consumers of your code won't actually need to have using statements. Those are there to make their lives easier, so they don't have to type antlr.collections.Foo and antlr.collections.Bar all over their source.

The bigger "impact" (if indeed there really is a severe one) is that the consumer of your code will need a hard reference to the assembly where antlr.collections is defined.

However, if that's documented up front, I honestly don't see it being that big of a problem. It's no different than the consumer of a SubSonic-generated DAL needing references both to the generated DAL assembly and the original SubSonic assembly. (And, quite possibly, using statements as well.)

Dependencies are what they are. There's a reason classes are broken into namespaces -- primarily for organization and to reduce naming conflicts. Not knowing what classes are in the namespace you mention, I don't know how likely such a conflict actually is in your scenario ... But attempting to move the class from one namespace to another, or to hide the fact that such is needed by deriving a blank class from it, is probably not the best idea. It won't kill the consumers of your class to have another reference and using statement.

Answer 5

If you derive from the class and return your derived class, you'll make yourself responsible for providing all of the documentation for the return type.

I think you'll be doing the developers who use your library a disservice because they won't necessarily know that what they're really working with is a type from antir.collections (not that I even know what that is, but that's not the point). If the developer comes to StackOverflow.com searching for information on that return type, are they more likely to find information if the type is from a "common" library, or from yours?

Answer 6

The only solution is to hide the whole dependency to the type antlr.collections.AST.

You can use an Adapter fot that purpose.