This post originated from an RSS feed registered with .NET Buzz
by Jonathan Crossland.
Original Post: Do you think .NET namespaces are good to go?
Feed Title: Jonathan Crossland Weblog
Feed URL: http://www.jonathancrossland.com/syndication.axd
Feed Description: Design, Frameworks, Patterns and Idioms
Namespaces offer categorization within your classes and assemblies. Two assemblies could be adding to 1 or more namespaces. But are you not increasing getting two problems.
More and more classes in more and more namespaces. After you look at the Enterprise Library or one of your own applications, or Object Models to give to a client, I bet you have many Types you wish you could hide from them.
Except for adding MyNamespace.Data or some other categorization, a namespace is pretty much useless. They cannot be made private, internal or anything else.
[code:c#]
Namespace MyNamespace
{
//they are always public - no modifiers or accessors allowed.
}
[/code]
What I find confusing, is how we can get complex features like Generics, but not easier features like namespace control.
The problem
As the .NET Framework grows, and it is continuously, we need to be able to better facilitate visibility across our Assemblies.
If you add the number of Types within the number of Namespaces that you reference compared with Types within those Namespaces that you actually use, you will probably find a huge range from project to project.
ActualUsed(Namespaces) is a subset (⊂) of
Total (Namespaces).
How would you write it as an insignificant subset?
When you get your Intellisense window up, you are confronted with miles of Type Definitions, that not only do you not need, but the developer probably never wanted you to actually see it either.
I touched on visibility of classes and members in a previous post regarding Modifiers and InternalsVisibleTo which is not the answer. (although a lot of people seem to site it as a silver bullet, its actually limited.)
What we need is to be able to mark a Namespace with private and internal etc.
We can therefore hide classes within these from the client. Also the whole "x is less accessible than y" needs to be looked at.
Problems
If a Type X has a Property of Type Y. X is contained within Public Namespace, but Y was declared within an "Internal Namespace", it should compile and run without problem. The user should then only see TypeY when in the context of TypeX.
The above rule in psuedo code:
[code:c#]
publicclass client
{
//from intellisense//visible
MyNamespace.TypeX
MyNamespace.TypeX.TypeY.Name // TypeY creatable because its created by TypeX//NOT Visible - ie. Not creatable
MyNamespace.Data.TypeY -
//TypeY not creatable because it cannot be created outside of TypeX
}
publicnamespace MyNamespace
{
publicclass TypeX
{
//Accessible and visible to this Assembly as TypeX.TypeY and public TypeY Property
{
get
{
return _Property;
}
set
{
_Property = value;
}
}
}
}
//Accessible and visible to this Assemblyinternalnamespace MyNamespace.Data
{
//Accessible and visible to this Assembly as MyNamespace.Data.TypeXpublicclass TypeY
{
publicstring Name
{
get
{
return _Name;
}
set
{
_Name = value;
}
}
}
}
[/code]
Conclusion
None of this would change the way you currently do things, just enable you to better fine tune it. If we have the power (including the .NET Framework libraries to change what is visible in this way, we will be reducing the amount of types and namespaces presented to us within intellisense. We would be able to present a smaller amount of Types and namespaces to our clients (they do get confused or rather scared of something large). Microsoft would benefit from making the .NET Framework appear smaller that it is, programmers would not see namespaces they dont need to see.
Previous Topic
