Using static classes as namespaces addresses something I was just complaining about a week ago. Let's take it a step further! Just let us put bare functions in namespaces without the dance of the static class.
>Let's take it a step further! Just let us put bare functions in namespaces without the dance of the static class.
No. C# is an object-oriented language. It doesn't have functions, it has methods. Methods are always attached to a class. Even anonymous methods (lambdas) are compiled to be a method on a class (like c__DisplayClass1).
If you think that way, then C# left you behind a long time ago. Because if functions had no place in C#, then there would be no static classes in the first place. The static class is nothing more papering over object oriented bureaucracy that "everything is an object" to provide functions. And using a static class as a namespace furthers that.
I get that the CLR expects a certain way of implementing things. But your own example of Lambdas are an excellent example of how we can use syntax to overcome bureaucracy in the runtime, or else we would be stuck in Java land with anonymous classes implementing interfaces.
Ultimately, it's all sugar. If a static method of a static class can be made to look like a function in calling code, then it makes sense to make it look like a function in the definition.
> The static class is nothing more papering over object oriented bureaucracy that "everything is an object" to provide functions.
Classes (in typical static, class-based "OO" languages like C++/Java/C#) aren't objects, and static classes are classes that don't even relate to objects the way that "normal" classes do. Static classes as containers for functions aren't papering over object-oriented bureaucracy that "everything is an object", they are papering over class-oriented bureaucracy that "everything is connected to a class".
(This is a general agreement with your basic point, though.)
